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FOREWORD 


This Technology Conference is the second such conference which 
the NASA Headquarters ADP Management Branch has sponsored. The 
first conference had the same theme (NASA Administrative Data 
Base Management Systems) , and it was held at the Jet Propulsion 
Laboratory on May 26 and 27, 1982. The proceedings of the first 
conference were published as NASA Conference Publication 2254. 

The purpose of these conferences is to provide an open forum 
for constructive exchange of information among NASA technical 
Automatic Data Processing (ADP) personnel. The theme for each 
conference is selected by conducting a survey of NASA ADP per- 
sonnel. The theme for each conference is selected by conduct- 
ing a survey of NASA ADP personnel through the NASA Inter-Center 
Committee on ADP. 

James D. Radosevich, NASA Headquarters ADP Management Branch 
(Code NXD-2) , was conference chairman. The conference was held 
at the Goddard Space Flight Center (GSFC) on May 25 and 2‘6, 1983. 
Conference arrangements at GSFC were the responsibility of Paul 
H. Smith, Head, Information Management Branch of the Applications 
Directorate; Joseph L. Barksdale, Assistant Director for Center 
ADP Planning; and Donna M. Smith, Information Management Branch. 

Presentations were made by 15 of the 73 people who attended. In 
addition the attendees had the opportunity to tour several GSFC 
data processing facilities and to attend a dinner meeting at 
which a presentation was made by Barry E. Jacobs, Assistant Pro- 
fessor of Computer Science at the University of Maryland. 
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1. NASA's EMERGING PRODUCTIVITY PROGRAM 


David R. Braunstein 
Executive Director, Special Project 
National Aeronautics and Space Administration 
Washington, D.C. 


ABSTRACT 


NASA, as one of the nation's foremost research and develop- 
ment agencies, has established a reputation for superior 
R&D management. Recognizing that severe budgetary and 
manpower constraints are likely to become the conditions under 
which we operate in the years ahead, NASA formed a Productivity 
Steering Committee to develop an agency-wide approach to pro- 
ductivity and quality. This approach would provide, in the 
long term, the best possible work at the highest level of 
quality under the constraints of a constant work force and 
tighter budget. The chairman of this committee is the NASA 
Administrator and the membership includes key Headquarters Ad- 
ministrators- and all Center Directors. 

NASA's agency-wide effort, established less than one year 
ago, is focused on seven strategic goals and is decentralized 
in its implementation and centrally coordinated by the Steering 
Committee. No centralized productivity staff is contemplated. 
Instead, part-time productivity coordinator networks and working 
groups have been formed at Headquarters and at the centers to be- 
gin specific initiatives for the seven goals. Under these goals 
several agency-wide tasks have been initiated, which include re- 
ducing paperwork, cutting procurement leadtime, increasing con- 
tractors' productivity, developing common administrative ADP, pro- 
moting office automation, initiating NASA Employee Teams, and 
reducing impediments to productivity. 

As evidence of management's commitment to productivity, the 
Agency recently published its eight top goals; prominent among 
them is to "Establish NASA as a leader in the development and 
application of advanced technology and management practices which 
contribute to significant increases in both Agency and national 
productivity." 

Productivity Program at NASA 


NASA has become engaged in a new high-payoff productivity pro- 
gram that is quite different from its normal projects. It is 
similar in that it involves am ambitious objective, major unknowns 
and difficult measurements, but instead of an aircraft or a satel- 
lite development, the application is to people and the management 
process. One might classify the program as "high-tech" manage- 
ment because of the similarity in "difficult to overcome" issues 
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between the productivity program and other NASA hardware develop- 
ment projects. In productivity the development issues involve 
beueaucratic processes, congressional, organizational and contrac- 
tor planning and control, and the built-in constraints in Govern- 
ment approaches to doing business. Our Administrator's goal is 
for NASA to become a leader in the development and application of 
productivity and quality concepts at every level of NASA manage- 
ment. The program is called PIQE for Productivity Improvement and 
Quality Enhancement, and we usually refer to it as simply the Pro- 
ductivity or PIQE program (productivity and quality going together 
and being equally important) . 

Productivity is important to NASA fundamentally because we have 
many more good ideas that need funding than we have dollars and 
people available to support them. Consequently, in a very tight 
budget environment it is in our own best interest to become as 
effective as possible in increasing our Agency output relative to 
the people and dollar resources appropriated to us by Congress. 

In addition we are an aggressive organization with very high morale 
and have a relatively low tolerance for program failures and bu- 
reaucratic nonsense. We take great pride in our creative environ- 
ment and our technical and management reputation and see the pro- 
ductivity program objective as a means to focus our management 
attention on initiatives to further improve the working environ- 
ment for NASA employees and to increase its organizational effec- 
tiveness. As implied in the figure below productivity and crea- 
tivity are closely linked in an R&D environment. 


Controls : That Discourage Variation from Norm 

Budgets : Without Leeway for Discretion 

Concensus/Committee : Emphasis Leading Toward Too 

Much Uniformity 

Recognition System : Encouraging Low Risk for Rewards 

Centralization Management : Resulting in Layering, Too 

Many People Who Can Say No 

Credit Due Limits : Failure to Give Recognition for Unusual 

Ideas in a Person's Job, Tendency to 
Forget Individual and Reward Supervisor 


Figure 1-1. NASA PIQUE Program Factors That Hamper 
Productivity and Creativity. 
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Besides NASA's own self-interests, productivity is important 
to the nation because of the impact it can have in maintaining a 
competitive technical and business position in the United States. 
Over the last five years productivity increases in the United 
States have been around zero. For most of the post-World War II 
period it was about three and a half percent. This is in sharp 
contrast to other major industrial nations which are enjoying 
larger positive productivity increases so that our productivity 
trend is widely recognized as an issue of national concern. Many 
corporations see it as a "survival" issue since other countries, 
notably Japan and Germany, are perceived to produce much better 
quality products and seem to have overtaken the U.S. in some 
rather basic and important industries such as steel, automobiles, 
and some high-volume electronic equipment. As an important RND 
Agency in the United States, NASA and its contractors have an 
opportunity to make a significant contribution by determining 
we can improve our productivity, measure the results, and md 
institutionalize its methods and approaches for long-term 
continuous pay-off. 

Challenges of a Credible Government Program 

Over the last several years, industry has taken an active 
interest in productivity because of the basic issues of maintain- 
ing compet i veness and economic survival. Tnere are many signs of 
this interest in the press, in trade journal articles, and in the 
growth of professional organizations. For example, the American 
Productivity Management Association has grown in the last 2 years 
from only 15 members to over 250 by word-of-mouth. Attesting to 
the importance of productivity to corporations, most productivity 
directors report to the corporation president or chief-executive 
officer, and productivity goals are part of the corporation's 
strategic planning. 

However, at NASA the challenge of maintaining interest in 
productivity will be more difficult. Unlike our corporate 
counterparts, we don't face the same economic issue. Where is 
our competition? Can you see NASA going out of business? Thus, 
while many of the very same issues of productivity in the 
organization exist in industry and in NASA, the sense of 
urgency or importance is different and the commitment will be 
more difficult to sustain. 

NASA's Administrator and its top executives recognize that 
productivity is a national problem and believe we can do 
something about it at NASA. They recognize that there is both a 
payoff for the employee in a better, more satisfying job, and a 
payoff for the organization, using streamlined planning and 
execution processes, and encouraging a greater team-like environ- 
ment. In order to signal the importance of productivity to the 
NASA community, a top-level steering committee was formed. NASA 
is not being naive about the challenges in maintaining a credible 
program, but it recognizes the need to develop one. Its top 
management is committed to make it successful. 
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Figure 1-2. NASA Productivity Steering Committee. 


Elements of NASA Program 

NASA is a unique R&D organization regarded by many in 
Washington as one of the best-run government agencies. The 
approach NASA adapted in planning its productivity program was to 
build on what is believed to be its inherent strengths, by 
emphasizing a program that focused on its people and a creative 
environment. To this end, efforts were undertaken to increase 
employee involvement in the decisionmaking process and to 
examine approaches to provide greater recognition and rewards for 
successful efforts. The productivity program aims to streamline 
the paperwork and control processes to permit a more creative, 
less burdensome work environment and to free the professional 
work force to spend greater time on project planning and execu- 
tion . 


• STREAMLINE MANAGEMENT PROCESS. REDUCE 
IDENTIFIED IMPEDIMENTS 

• INCREASE CAPABILITIES, COMMITMENT. MOTIVATION 
OF STAFF 

• STIMULATE INDIVIDUAL AND GROUP INITIATIVE 
TOWARD PRODUCTIVITY IMPROVEMENTS 

• PROMOTE THE INTRODUCTION OF EFFECTIVE 
MANAGEMENT APPROACHES. ADVANCED 
TECHNOLOGY. AND INSTITUTIONAL MODERNIZATION 

• INCREASE TIME AVAILABLE FOR PROFESSIONAL STAFF 
TO BE CREATIVE 


Figure 1-3. NASA PIQE Program Key Objectives. 
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Further, the productivity program involves a long-term 
commitment by top management. This has been important so that 
middle management support would evolve. Initial management reaction 
in the early stages of the program planning at NASA was similar 
to that of other successful corporations starting a productivity 
and quality improvement program: "Productivity seems to be more 

political than real, and 1 only have time available to spend on 
initiatives that are really important." It was necessary to 
overcome the basic feelings that "productivity was just another 
Washington fad." Mr. James Beggs, our Administrator, dealt with 
these initial reactions by first taking NASA's top managers to 
Westinghouse Corporation's Productivity Center for an orienta- 
tion. There, the Associate Administrators and Center Directors 
heard, first-hand, what convinced Westinghouse that productivity 
was an important strategic goal which needed special emphasis. 

Then, a series of briefings, lectures and workshops were 
initiated to raise the consciousness level of our management and 
to allow them to develop their own interests and ideas. Finally, 
in order to help plan our program, we surveyed the NASA 
Headquarters Center Program Managers and NASA contractors to 
determine their perspectives on impediments to productivity. Based 
on these comments, we are starting to develop suggestions as to 
what NASA should do to improve its productivity. The results pro- 
vide insights into what we could do to simplify our management 
planning, budgeting, coordinating, and controlling. Focal points 
for productivity were identified at the major NASA organizational 
elements, and teams of managers from different parts of the 
organization have been formed to look into tne issues raised and 
to recommend approaches to simplify the project manager's job. 

Initial Thrusts 


In initiating the NASA Productivity Program, efforts were fo- 
cused in seven strategic areas. Several short-term initiatives 
were immediately undertaken in response to the "impediment 
surveys" taken of NASA Project Managers in our field centers. 

The key initial objectives were to streamline the planning and 
budgeting process, reduce paperwork, promote office automation, 
and cut down procurement leadtime since these areas were fre- 
quently mentioned by the professional staff as impediments to 
their productivity. Task teams were formed to recommend 
corrective action that could alleviate the perceived problems. 

We expect to impact management practices with these investiga- 
tions and to encourage new approaches and the use of new 
technology into the NASA management process. 
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• HEIGHTENING MANAGEMENT AND EMPLOYEE 
KNOWLEDGE AND AWARENESS 

• ENCOURAGING PIQE MANAGEMENT PRACTICES AND 
NEW TECHNOLOGY TO INCREASE PRODUCTIVITY 

• BROADENING EMPLOYEE PARTICIPATION IN 
MANAGEMENT DECISION-MAKING 

• ESTABLISHING PROCESSES FOR DEFINING 
PRODUCTIVITY GAUGES AT EACH ORGANIZATIONAL 
LEVEL 

• IDENTIFYING PIQE IMPEDIMENTS AND OPPORTUNITIES 
FOR GREATER PRODUCTIVITY 

• DEVELOPING APPROACHES AND INCENTIVES FOR 
PROJECT AND CONTRACTOR PIQE ADVANCES 

• SHARING OBJECTIVES AND RESULTS OF CENTER PIQE 
EFFORTS WITH OUR PEOPLE 


NAM MO UKMWI 


Figure 1-4. NASA PIQE Program SEVEN TASK FOCUS. 


Key initiatives started and aimed at promoting participa- 
tive management and increasing employee involvement in the 
NASA's decisionmaking processes are 1) NASA Employee Teams, 

2) Nominal Group Technique Training for supervisors, and 

3) revitalization of our employee suggestion system. Our 
NASA Employee Teams involve training employees in the "quality 
circle" processes that provide insight and techniques in par- 
ticipative management and team problem solving. Similarly, we 
initiated the nominal group technique training and a new em- 
ployee suggestion program to increase our employee participa- 
tion in addressing ways to increase our organizational and op- 
erational effectiveness. 

Productivity trends measurement for our agency is being 
pursued on a decentralized level. We recognize the need to 
engage our employees in the goal-setting process and feel that 
meaningful productivity measures should be decided at the branch 
level. Consequently, our approach has been to decentralize the 
measurement process to the point at which groups of employees can 
agree on their own objectives and measurements of their own 
progress. In this way we expect to build in the process of pro- 
ductivity awareness and take advantage of the pride and natural 
desire of the staff to improve their efforts. The objective will 
be to increase results and accomplishments at each level relative 
to costs in terms of manpower and dollar investment. 
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Figure 1-5 


Finally, we will hold periodic conferences and briefings to 
allow each NASA organization activity and our contractors to 
discuss their respective programs and ideas to improve produc- 
tivity. Our objective here is simple. We recognize the 
motivation for the organization to learn and develop its own 
techniques and approaches, and we have facilitated this learning 
process by providing a forum for discussion. In order to pro- 
vide a continuous structure for this process, a productivity 
council consisting of representatives from the various NASA organi- 
zations has been set up, and we have initiated meetings with our 
contractors . 


Overall Strategy 


We recognize that for NASA the key to achieving productivity 
improvement is through employee involvement, both civil servant 
and contractor, in all phases of our activities. While NASA's 
leadership role in research and development demands increased 
investment in technological advances, technology alone is not 
sufficient unless supported by motivated and dedicated people. It 
takes people to put this new technology to work, people who are 
challenged and willing to accept change and embrace new ideas. 
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Figure 1-6. PIQE Coordination Network. 


Our industrial contractors, concerned with their competitive 
edge, and NASA's own concern with our nation's aerospace preemi- 
nence, dictates that we must strive to improve our individual, 
organizational, and national productivity. By encouraging and 
rewarding increased productivity through the use of advanced 
technology and management innovation, NASA will be in a position 
to make a significant contribution to the nation's productivity 
in both the public and private sector. 

In our productivity briefings, we have found that NASA's 
employees and our contractor community are receptive to this 
challenge. One need only examine NASA's accomplishments over 
its brief 25-year history to be assured that the talent and the 
capability exist in our combined organizations. The NASA team 
expects to provide the continued leadership in aeronautics and 
aerospace, and in addition, to make new strides in productivity 
improvement and quality enhancement. 
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2. ACTION INFORMATION MANAGEMENT SYSTEM (AIMS): A USER'S VIEW 


Michael Wiskerchen 

Office of Space Science and Applications 


The AIMS project at NASA Headquarters has now reached its fourth 
year of life. It was born out of the frustrations and needs of 
the technical management staff of NASA Headquarters. The complex 
management tasks connected to NASA's flight programs demanded 
modern information technology tools. The traditional batch mode 
data processing office did not fulfill the needs of this emerging 
user group. It is important at this time to reflect on the 
successes and failures of this project to satisfy the needs of 
this technical management group. 

The primary objective of the AIMS project was to establish a user- 
defined information system to fulfill "user needs" at NASA 
Headquarters. I specifically stated user needs and not user 
requirements. The difference between needs and requirements is 
significant. Since none of the potential users had experience 
with such systems, any stated requirements could only be 
perceived from limited knowledge. A requirements study at that 
early stage could only be the summation of our total ignorance. 
From our technical backgrounds we knew that certain baseline 
conditions should be met. A systems engineering approach 
must be used. Our experience with flight system hardware and 
software also dictated an approach. The architecture of the 
system should be an interactive distributed system available to 
all Headquarters users. The system should possess a user- 
friendly query language data base and all software should be 
commercially available to reduce development and maintenance 
costs . 

The methodoloqy used to establish the project was driven by both 
.engineering and political considerations. A dedicated user 
team was set up with membership from each principal office. The 
project was established as an R&D pilot activity. This was 
essential because it was our traditional means of doing technical 
projects, and also it avoided the usual hassles involved with 
procuring management ADP equipment. It was called a pilot and 
developed as a pilot to avoid the pressures of having to have a 
development system that was used on our mandatory daily tasks. 

If any particular part of the system did not work as expected, it 
could be modified or dropped without undue difficulty. We hired 
contractors to work with us on program development and training 
of our personnel. The central computer in the system was 
obtained by using a flight mission computer at Goddard Space 
Flight Center, and the necessary commercial software was put on 
it. The Headquarters peripheral equipment was either purchased 
or leased. 
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Over the past several years we have learned a great deal from 
this project. The most important effect of the AIMS project was 
the establishment of a close-knit team of users across the 
Headquarters offices. The success will be evidenced by the 
presentation of Phyllis Hayes following this talk. I will 
concentrate the rest of my presentation on some of the failures 
of the AIMS pilot. For one thing, NASA Headquarters is not 
suitably organized to carry out all of the required tasks of 
an R&D project. It was clearly recognized that in other R&D 
projects NASA Headquarters plays a significant management role 
but depends completely on field center project support for all 
engineering tasks. Because of this Headquarters inexperience, 
full project status was never achieved. Insufficient contract 
personnel were hired; no Headquarters personnel were directly 
assigned to the project, and no integrated training program was 
established. This also led to hardware and software procurements 
always being behind schedule. 

Even with all of these difficulties, the AIMS pilot project found 
the road to success. This was primarily due to a dedicated group 
of users from Codes E, N, R and T who would not let the project 
fail. Ames Research Center was designated as the lead 
field center to work with Headquarters. ARC gave the AIMS pilot 
full project status with the necessary personnel assigned to it. 
Key milestones and tasks were established for the project. The 
first results, the RTOP system, will be demonstrated to you in 
the following talk. This RTOP system can be seen as a true 
success and something that should be emulated in future tasks. 

In conclusion I think several things should be recognized. NASA 
should always work from its organizational strengths as a 
Headquarters-Center partnership. The strong teamwork and 
friendships developed during this effort should be utilized and 
encouraged by the Agency for establishing future management 
systems. 
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USER DEFINED SYSTEM TO FULFILL "USER NEEDS" AT NASA HEADQUARTERS 

• INTERACTIVE DISTRIBUTED SYSTEM AVAILABLE TO ALL HQ USERS 

• "USER FRIENDLY" QUERY LANGUAGE DATA BASE 

• COMMERCIALLY AVAILABLE SOFTWARE 


Figure 2-1. Aims Objectives. 


FORM HEADQUARTERS USER TEAM 
ESTABLISH R & D PILOT PROJECT 

• USE EXISTING FLIGHT PROJECT COMPUTER AT GSFC 

• BUY OR LEASE PERIPHERAL EQUIPMENT FOR HEADQUARTERS USERS 

• BUY COMMERCIALLY SUPPORTED SOFTWARE 

• EMPLOY CONTRACTOR DEVELOPMENT SUPPORT 
ESTABLISH FULL TRAINING PROGRAM 


Figure 2-2. Initial Methodology. 



HEADQUARTERS UNPREPARED TO CONDUCT ALL ASPECTS OF R & D PILOT PROJECT 

• PROJECT STATUS FOR PILOT NEVER REALIZED 

• CONTRACT PERSONNEL INSUFFICIENT 

• NO HEADQUARTERS PERSONNEL DIRECTLY ASSIGNED TO PROJECT 

• INTEGRATED TRAINING PROGRAM NEVER ESTABLISHED 

• HARDWARE & SOFTWARE PROCUREMENTS BEHIND SCHEDULE 

• TRADITIONAL CENTER INVOLVEMENT LACKING 

Figure 2-3. Lessons Learned. 


• NEVER- SAY- DIE USERS 

• FULL CENTER INVOLVEMENT (AMES RESEARCH CENTER) 

• FULL PROJECT STATUS 

• KEY MILESTONES ESTABLISHED 

• POSITIVE RESULTS (RTOP SYSTEM) 

• METHODOLOGY MUST INCLUDE ORGANIZATIONAL STRENGTHS 


Figure 2-4. Road to Success. 



AUTOMATED RTOP MANAGEMENT SYSTEM 


Phyllis Hayes 
Headquarters Code RP-4 



FY 1983 


ARC 

VAX-1 1/7801S) 


HQ ADMINISTRATIVE 
IBM MAINFRAMES 


TELEMAIL 


OTHER HQ 
PROGRAM 
OFFICES 


EXISTING TELEPHONE LINES. SYSTEMS, SERVICES (DIAL-UP ACCESS) 



PC-350 
APPLE I 



III 

■ *?y uwg3H i 


PC-350 

TEKTRONIX 


MANAGEMENT 

• TELEMAIL 

- ELECTRONIC MAIL 
> ALL-IN-1 

- INTERACTIVE COMPUTING 


PROGRAM SUPPORT 

• TELEMAIL 

- ELECTRONIC MAIL 

• ALL-IN 1 


• INDEPENDENT 
COMPUTING 
- APPLICATION 
DEVELOPMENT 


SECRETARIAL 

• TELEMAIL 

- ELECTRONIC MAIL 

• ALL-IN 1 


• WORD PROCESSING 

- OOCUMENT PREPARATION 
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Figure 3-4. RTOP Automated System 


TAKES ADVANTAGE OF EXISTING HARDWARE, SOFTWARE, AND EXPERTISE 

MINIMAL DEVELOPMENT TIME AND COSTS 

PROJECT INITIATION 9/82 

SYSTEM DEVELOPMENT 12/82 

FIRST TEST TRANSMISSION 3/83 

LIMITED SYSTEM 6/83 

COORDINATED WITH HEADQUARTERS EFFORTS IN CODES R, E, AND T 


Figure 3-5. Prototype System Development at Ames 

Research Center. 
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DEVELOPMENT EMPHASIS BY ON-BOARD CONTRACTOR SUPPORT 

PILOT TESTING 

INVOLVES EVERYONE WILLING 

....SHORT-TERM SCHEDULE 


Figure 3-6. Approach 



4. RAMIS DBMS Update 


James Head 

Goddard Space Flight Center 

I recently returned from a roundtable in Chicago of our DBMS. We had three and a half days of pres- 
entations, discussions and demonstrations. We had no less than six guest speakers, and I would like to share with 
you some of my notes on the topics germane to this presentation. 

The first speaker, John F. Rockart, is Director, CISR, and Senior Lecturer of Management Science from the 
Sloan School of Management, M.I.T. He spoke on “Managing End-User Computing.” John Gantz from International 
Data Corporation, of which Computerworld is a part, spoke on “IBM Strategies.” Richard H. Cobb of Mathematica 
Products Group, our host for the roundtable, spoke on the “Evaluation of Fourth-Generation Languages.” On a 
similar subject, Donald G. Ross of Database Research Group spoke on “Software Innovation, New Directions.” 

John F. Rockart had some eye-opening statistics and observations derived from an in-depth study of 271 
organizations, most of which were in the Fortune 1000. Since his talk lasted an hour and a half and summarized 
the study, I will make a few observations only. The first three slides represent where we’ve been as an industry. 


Figure 4-1 . 

The first chart is the traditional “Fast Calculator” application. It is almost always an accounting function (usually 
payroll) repetitive and unchanging. 

COBOL, in this era, was a new tool destined to free the programmer from machine languages. The programming 
staff would now have plenty of time to expand systems into other areas. 


Figure 4-2. 

The highlights of the 1960s include the decentralization of computing facilities. Distributed processing was the 
buzzword. Minis began to appear. 


Figure 4-3 . 

With the advent of large and powerful hardware combined with generalized software for applications development 
we saw a resurgence of centralized computing. It was the beginning of the DBMS. It was a rush into areas where 
angels fear to tread. 

I don’t think that there is anything surprising in any of these first three slides, but Rockart’s observations of the 
1980s are rather interesting. The growth rate in the 1950s and 1960s was generally in the 15 to 20 percent bracket. 
In the 1970s and projected for the 1980s is a growth rate of 50 to 100 percent. This growth rate is predicated 
on the availablility of a user-friendly DBMS. In fact, if you have had a DBMS installed for five years or more, 
the projection will approach 75 percent. 


Programming in the 1980s can be broken into six major categories: 


Figure 44. 

Why this explosion in end-user programming? 

o Vastly improved end-user software 
o New generation of computers 
o Micros/PCs 
o Hardware costs down 
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o User frustration/demand 
o Programmer availability 
o Availability of external data bases 
o Availablity of internal data bases 


Figure 4-5 

Richard Cobb, President of Mathematica Products Group, spoke on the “Evaluation of Fourth-Generation 
Languages.” He said that: 

o COBOL is not yet a dead language, but it is clear that it is dying . 
o Forty percent of all programming is being done by end-users in the leading companies, 
o Five percent end-user computing by the trailing companies . 
o By decade’s end 75 percent of all computing will be done by 4GL. 
o Problem: 50 million office workers supported by 625,000 computer specialists. 

Solution: teaching the computer to speak a language that is closer to the language that people use 
every day. 

Mr. Cobb believes that we have gone through five evolutions of computer languages: 

o Machine language 
o Assemblerlanguage 

o Higher level languages (COBOL, FORTRAN, etc.) 
o Programming aids (DBMSs, report writers, etc.) 
o Nonprocedural languages 

Some of the key points in defining a nonprocedural language include the following: “Taking the programmer out 
of the loops.” This is a slight play on words. Assembler programs have an instruction register that controls the 
flow of a program. In COBOL the control register is still present but not directly controlled by the programmer. 
The order, or careful control of the loops, is still very much a requirement. The nonprocedural language removes 
this concern. For the fourth generation language to be truly effective, it must contain data base management capa- 
bility as in integral component. The ones that prove most effective are the ones that respond interactively in the 
form of an ongoing dialog to the questions the user poses. 

Ronald G. Ross of Database Research Group, Inc. continued the theme in his presentation: “Fourth Generation 
Languages: A Definition.” 

One interesting observation is that DP organizations are getting better in implementing applications and yet the 
backlog of applications is growing at a faster rate. Experts agree that a crisis exists in computer productivity, and 
most agree that the solution is to get end-users, as much as possible, into their own special processing. The 
tools may very well be available on today’s market. Products like RAMIS, FOCUS, and INTELLECT provide the 
nonprocedural, user-friendly language necessary for this approach to the backlog dilemma. 

Ross presented 10 defining criteria for 4th generation languages. 


Figure 4-6 

I would like to take these 10 criteria and compare them to our DBMS, RAMIS. 


Figure 4-7 
Criteria 

1 . Result-oriented programming 
o Nonprocedural language 
o English-language processor 

— Did at least four customers order pumps in March? 
— How many units of each product have we sold? 

— Which customers purchased more than 5000 units? 
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The English Language Processor uses three dictionaries: 

o General dictionary of the English language 
o RAMIS II file dictionary 
o File Specific dictionary 


Figure 4-8 

2. Common Language/Demand Level Adaptability 

o Programmer and the user community speak a common language. 

o Numerous defaults for the end-user, program development tools for application development, 
o Macros and menus for the end user. 

o Formatted screens: define executive functions for the experienced programmer. 


Figure 4-9 

3. Application Expansion 

o Growth in capability 
o Growth in usage 

o The “Relate” component allows access RAMIS, QSAM, VSAM, ADABAS and other file structures 
to be combined for information processing, 
o RPI allows access via COBOL, FORTRAN, Assembler, etc. 
o Concatenation of databases (up to 16) 

o Database Information System — Central Dictionary Component 

4. User/Machine Insulation 

RAMIS offers complete portability between different system environments. For example, a RAMIS II 
application running under CICS with 3380 disk drives could be transferred to another machine running 
TSO using 3330 disk dirves with 2 commands — one command to unload the database and one command 
to reload to the new environment. 

5. Work Station Environment 

The ability to store current tasks and recall them with ease is an important requirement in the work station 
environment. In addition, the capability of building onto existing prior efforts, or incorporating standard 
routines into the current process is vital in the development process. RAMIS II solves this problem with 
a number of features. In the interactive environment, procedures can be stored via a catalog command. 
RAMIS has its own editing capabilities called Interactive Request Modification Requests, which can be 
copied and merged on command. 

Data files or requested subsets of files can be retained by the “HOLD” command, often called a “scratch 
pad. These files can become permanent files by requesting the “HOLD” file to be “ALTERED” to a per- 
manent file. RAMIS will create the proper dictionary for the new file. 

Figure 4-10 

6. Comprehensive Software Toolkit 

The RAMIS system has an excellent supply of software aids or features for the experienced programmer. 
For example REF provides an external file interface to sequential, ISAM, or VSAM files. In addition 
RAMIS can “TALK” to other DBMS files such as DL/I , TOTAL, IDMS, and ADABAS. The “RELATE” 
feature will combine any of these file types into a data base for reporting purposes or for permanent 
storage. RAMIS has a simple yet powerful high resolution graphics capability. A simple table request 
can turn into graphics with one command, i.e., “PLOT PIE.” 

7. Integrating Perspective on Computing and Data Resources. 
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Figure 4-1 1 


For the end user or the non-data-processing user, the system must operate in a consistent and friendly 
fashion. Access to data must be the same regardless of how the data is stored. RAMIS provides this 
for the end user through its query language facility. A single access strategy is automatically provided 
for any query. 

8. End User Data Base Capability 

With the recent product announcement of “ENGLISH,” RAMIS has joined “INTELLECT” in being 
the only two products based on artificial intelligence technology. RAMIS II English learns through 
the dialogue process. As the user responds to questions posed by English, the systems knowledge base 
is automatically and dynamically enriched, improving fluency. 

The existing query language of RAMIS II is a very powerful tool for all users. With this announcement the 
product is as good as anything on the market today. 

When you consider the relational capabilities, access to many varied file structures and high resolution 
graphics, all driven by an English-like language, you have a very powerful software tool regardless of 
the experience level of the end user. 

9. Accessible Dictionaries 

RAMIS II provides access to the dictionaries via canned queries. Users may write queries against any dic- 
tionaries since they are stored in a RAMIS II file. 

RAMIS II also has a central repository of dictionary information available for use. This particular fea- 
ture is another product of the system. 

10. User Assistance/Facility Coordination 


Figure 4-12 

RAMIS II has a number of tools in this area, the most direct being a hot line in Mathematica called RAMIS 
Technical Assistance (RTA). Canned queries are also available. For example, the RAMHELP query is 
menu-driven to provide information, structure, and examples for most areas of their product. RAMERROR 
provides information about error conditions, and if possible, solutions to the problem. 

RAMLEARN is a new product that assists the new user via computer dialogue. The computer will remem- 
ber where the user stops for the day and will continue from that point. It will also allow the user to 
return to previous segments or the experienced user to browse for key points. 


Figure 4-13 

New features and product enhancements are also available as a RAMIS II data base and is menu-driven. 

The 1980s will be a very interesting era. We have speech synthesizers on home computers now. By 
decade’s end someone will surely have speech recognition as part of a DBMS. 

I also see more intelligence in our end-user community in using this common language. We are communi- 
cating, and they are asking— not if, but when— we will have full screen capabilities and when graphics 
will be available. We are seeing demand “pull” rather than technology push. We now have the horse before 
the cart, and we had better be in the cart. 
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Figure 44 


24 



END-USER DEVELOPMENT 
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Figure 4-5 


o RESULT-ORIENTED PROGRAMMING 

o COMMON LANGUAGE/DEMAND LEVEL ADAPTABILITY 

o APPLICATION EXPANSION 

o USER/MACHINE INSULATION 

o WORKSTATION ENVIRONMENT 

o COMPREHENSIVE SOFTWARE TOOLKIT 

o INTEGRATING PERSPECTIVE ON COMPUTING AND DATA RESOURCES 

o END-USER DATABASE CAPABILITY 

o ACCESSIBLE DICTIONARIES 

o USER ASSISTANCE/FACILITY COORDINATION 


Figure 4-6. Ten Defining Criteria for Fourth Generation Languages. 
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ramheLp new 

Section Menu for Release 83.1 of RAMIS II 

1 Reporting Extensions 

2 Formatted Screen Manager 

3 RELATE 

4 Automatic: Interface to IDMS 

5 Integrated Terminal Commun i ca t i ons (ITC) 

6 DataBase Information System (DBIS) 

7 New Executive Features 

8 VALIDATE Function 

9 ICCF Procedure 

10 RAMXEDIT Procedure 

11 RAMQFFLK User Exit 

12 Other New Features 

13 Ef f i c i ency 

14 Upward Compatibility in Release 83.1 

Enter number for section desired; MAIN for main menu; 
STOP to exit; or press enter key to redisplay section 


Figure 4-10 
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rapgjjjfor dm^120 

ERROR DESCRIPTION FOR DATABASE MGMT ERROR CODE DM0120 (64) 


TEXT: 
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ACTION 

ACTION 

ACTION 

ACTION 
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ACTION 

ACTION 

ACTION 

ACTION 

ACTION 

ACTION 

ACTION 

ACTION 
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ERROR IN VIRTUAL SEGMENT DESCRIPTION IN FILE 'FILENAME' 
AT FIELD F 

AN ERROR HAS BEEN DETECTED IN THE LINKAGE 
CHARACTERISTICS AS THEY RELATE TO THE ASSOCIATED 
FILE. ANY COMBINATION OF THE FOLLOWING CONDITIONS 
HAS BEEN DETECTED FOR THE FIELD SHOWN IN THE MESSAGE. 

1 . A KEY LEVEL IN THE CROSS LINK IS GREATER THAN 
THE DATA LEVEL. 

2. THE NUMBER OF KEYS ON A GIVEN LEVEL IN THE 
ASSOCIATED FILE AS DEFINED BY THE CROSS LINK 
EXCEEDS THE NUMBER OF FIELDS IN THAT LEVEL. 

3. THE NUMBER OF FIELDS SPECIFIED IN THE RAMKEY 
FOR THE ASSOC. FILE EXCEEDS THE NUMBER OF 
ENTRIES DEFINED IN THE CROSS LINK. 

4. THE DATA LEVEL IN THE CROSS LINK IS GREATER THAN 
THE NUMBER OF LEVELS IN THE ASSOCIATED FILE. 

5. AT LEAST ONE OF THE LEVEL SPECIFIED IN THE 
CROSS LINK FOR KEY OR DATA IS A VIRTUAL 
LEVEL IN THE ASSOC. FILE. 

6. THE RAMASTER DICTIONARY DOES NOT CONTAIN A 
DESCRIPTION FOR THE ASSOCIATED FILE NAMED. 

MSGLEVEL OPTION SET AT G 


Figure 4-1 1 
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Figure 4-13. TSO Usage by Function. 
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5. INTERCENTER PROBLEM REPORTING AND 
CORRECTIVE ACTION SYSTEM 
(PRACAS ) 

Georgia H. Brock, NASA 
James J. Paley, CSC 
John F. Kennedy Space Center (KSC) 


ABSTRACT 


Accelerated launch schedules have magnified the need for rapid ex- 
change of information concerning open problems and historical engi- 
neering data that contributes to problem resolution. The Kennedy 
Space Center has begun work to transform the PRACA Batch Automatic 
Data Processing (ADP) System of today into a fully integrated data 
base with on-line update and retrieval capabilities. The present 
manual system of reporting (Datafax, mail/ and telephone) to the 
off-site design and engineering organizations will be replaced by 
direct access to the most current information as it accrues at KSC 
or VAFB. Two major goals of the Intercenter PRACA are to provide a 
single data depository for both launch sites and to fully integrate 
the problem data with engineering data as well as other relevant 
information. The resulting ADP system will provide a closed loop 
system for problem reporting, corrective action and recurrence con- 
trol that should serve the engineering community as well as relia- 
bility and quality assurance at the launch sites, KSC and VAFB, and 
at the design centers, JSC and MSFC. 


I . INTRODUCTION 


The Level II Change Request S21701 charges KSC with the re- 
sponsibility for conducting an optimum data system study to 
establish PRACA requirements for Space Transportation Systems 
(STS) Operations at JSC, MSFC, VAFB/ and KSC. The study 
addresses the STS operational era needs of two-week orbiter 
turnaround and defines a phased transition from the era of STS 
Design, Development, Test,, and Evaluation (DDT&E). Computer 
Sciences Corporation is conducting a top-down study which 
will define the intercenter PRACA development cycle up to the 
prelimary design phase of a structured systems development 
methodology. Upon completion of the study in August 1983, and 
resolution of any variances discovered during the review cycle 
in September 1983, the study will be offered for final review 
and acceptance by the Level II Space Shuttle Program Require- 
ments Control Board in October 1983. This paper will include a 
definition of the PRACA discipline, the background and manage- 
ment of the ADP development, and the current and proposed 
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PRACA ADP Systems. The proposed system will be defined within 
the context of the Kennedy Data Management System (KDMS), the 
KSC-wide Information Management System, and broken into phases. 
The KSC system has been approved through implementation, but 
the Intercenter system is subject to approval by Level II prior 
to the detailed design phase. For this reason the schedules 
are coordinated but are kept separate. 


II. THE PRACA DISCIPLINE 


Problem Reporting and Corrective Action (PRACA) is one of 
the major functions of the STS Safety, Reliability and 
Quality Assurance (SR&QA) program. The discipline represents 
a structured system for the identification, analysis, correc- 
tion, and prevention of recurrence of hardware and software 
nonconformances. A nonconformance reflects a condition of 
any article, material, or service where one or more charac- 
teristics do not conform to requirements due to a failure, 
discrepancy, defect, or malfunction. Nonconformances are gen- 
erally categorized as problems or discrepancies. A problem 
is defined as any nonconformance that falls into category (a) 
or (b) as follows: 

(a) A failure or unsatisfactory condition that occurs 
during or subsequent to production acceptance test- 
ing. 

(b) A failure or unsatisfactory condition that occurs 
prior to acceptance testing that will or has the po- 
tential to adversely affect safety, contribute to 
schedule impact or launch delay, or result in a de- 
sign change. 

A discrepancy is a nonconformance that does not affect form, 
fit, or function; or that can be corrected by using previous- 
ly approved instructions, and does not require recurrence 
control. 

The life cycle of the PRACA process begins with the de- 
tection of a nonconformance, largely as a result of perform- 
ing planned work activities, such as tests and operations, 
maintenance, inspections, assembly /disassembly , etc. Upon 
detection, the nonconformance is reported and documented in a 
prescribed manner. At KSC a standardized form (KSC 2-151) 
has been developed for reporting the three classifications of 
nonconformances. Prior to engineering analysis, the noncon- 
formance is initially classified as an interim problem report 
(IPR). During analysis, using the criteria defined above, 
the final classification is either a Discrepancy Report (DR) 
or a Problem Report (PR). 
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Once analyzed and classified, the remedial action is de- 
lineated by the responsible engineer with instructions to 
accomplish the resolution. This action is referred to as a 
disposition and includes, in addition to instructions, a des- 
ignation of the skill level of the personnel, and the mate- 
rial and facilities required to perform the work. Upon com- 
pletion of all required tasks, the work is inspected by the 
responsible engineering and quality personnel and an approval 
is effected. At this point the nonconformance is closed and 
relegated to the historical information file. 

With this oversimplification of the PRACA process, it is 
essential to highlight the three alternatives to the noncon- 
formance resolution: (1) a local remedial action could com- 

pletely resolve the condition, (2) a local remedial action 
which resolves the condition could warrant further action to 
prevent a recurrence of the condition (recurrence control) , 
and (3) only recurrence control action could resolve the con- 
dition. 

Recurrence control is a design engineering activity. It 
includes failure analysis and redesign when required. Recur- 
rence control for Ground Support Equipment (GSE) is performed 
by engineering components at the launch sites. For flight 
equipment, it is performed within the various element con- 
tractors' organizations. 

Figure 1 is a logical depiction of the PRACA System at 
KSC. The form numbers shown in the boxes relate to the 
standardized documents used at KSC. By way of clarification, 
KSC 2-151 is the document used to report and track Interim 
Problems, Problems, and Discrepancies. This document also 
serves as a work authorization document to perform remedial 
action tasks. KSC 2-155 is a continuation sheet for KSC 
2-151. KSC 2-154 Corrective Action Assistance Request (CAAR) 
is employed when recurrence control is required. 

PRACA is one of eight major functional disciplines that 
require data base management at the KSC and VAFB launch cen- 
ters. While many of these functional disciplines are strong- 
ly interconnected, PRACA is directly related to (1) Mission 
Planning; (2) Work Control; (3) Safety, Reliability, and Qual- 
ity Assurance; (4) Resource Management; (5) Operations and 
Maintenance Directives; (6) Facilities, Systems, and Equipment 
Management; and (7) Configuration Management. Figure 2 
graphically depicts these relationships. By following uni- 
form procedures, the quality assurance function ensures that 
each nonconformance is properly corrected by engineering and 
is approved. The process results in (1) a record of malfunc- 
tions traceable to individual parts and vendors, (2) a trace- 
able link to the design engineering organizations when design 
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errors are suspected, (3) a trail of well -documented solu- 
tions - some by trial and error, (4) a central repository of 
detailed information about open problems that must be worked, 
and (5) a central repository of closed problems that provide 
trends and statistics for recurrence control activities. 

The information in the PRACA data base is useful to 
engineers concerned with operations, design, safety, and 
reliability and to managers concerned with various levels of 
the engineering disciplines and quality assurance. The 
technical problem report analysis is concerned with documen- 
tation, remedial action, recurrence control, failure analysis, 
and hardware disposition while the management problem analy- 
sis is concerned with visibility, status, and decision sup- 
port. For instance, an engineer looking for a solution to an 
open problem can query the PRACA data base for prior occur- 
rences and solutions of the problem; his manager can status 
open problems for work planning activities; and the quality 
assurance inspector can ascertain system reliability. Key 
data elements can be combined into well-formatted reports to 
serve a variety of purposes within the PRACA discipline and 
reports from the various systems can be combined to analyze 
data across disciplines. This necessity to combine data 
across disciplines by manual methods emphasizes the require- 
ment for a fully automated system that integrates information 
electronically . 

The addition of the intercenter requirements to the KSC 
system will serve to close the loop in tracking a nonconfor- 
mance "from the time of detection through the remove and re- 
place cycle and on to the resolution and recurrence control. 
The KSC PRACAS has always been a closed loop problem report- 
ing and corrective action system for ground support equipment 
(GSE), but for flight elements, the problem report is sent to 
the JSC and MSFC design centers and their element contractors 
where the problem tracking, analysis, and resolution task is 
performed independently of the KSC PRACA System. With the 
intercenter requirements, the system will become a uniform 
closed loop system for all flight, ground support equipment 
(GSE), and government furnished equipment (GFE, i.e. , space 
suits, manned maneuvering device, etc.). The PRACA inter- 
center relationships are shown in Figure 3. 



Figure 5-2. PRACA Functional Perspective. 
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III. BACKGROUND AND MANAGEMENT OF THE INTERCENTER OPTIMUM DATA 
SYSTEMS STUDY 


The genesis of the intercenter PRACA Optimum Data Study 
dates back to 1980. At that time JSC, under the direction 
of NASA Headquarters, conducted a study to determine the 
functional requirements of the PRACA discipline in the opera- 
tional era of the STS Program. In the following year, a ser- 
ies of meetings was held to analyze this basic information 
and to refine the requirements. NASA Headquarters, JSC, 

MSFC, VAFB, and KSC were represented in these discussions. As 
an outgrowth of these meetings, it became evident that due to 
the time constraints of the STS operational era, the centers 
would need to share the PRACA information efficiently in 
order to support accelerated operations and a broadened man- 
agement decisionmaking process. It is the major goal of the 
Optimum Data Systems Study to determine the most effective 
means to provide this capability. 

KSC has been designated as the NASA center with the re- 
sponsibility for conducting the study. As the major launch 
site, KSC has broad horizons in the PRACA discipline. These 
include reporting and recording all nonconformances detected 
during launch processing of the flight hardware and software 
systems as well as ground support equipment. Further, there 
is a detailed interest and involvement in all nonconformances 
that occur at KSC, and there is responsibility for transfer- 
ring and exchanging open item data with VAFB on shared orbiter 
and common facilities and ground support equipment. More- 
over, KSC has the recurrence control functional responsibil- 
ity for all ground support equipment at both KSC and VAFB. 

KSC is currently defining the requirements for a signifi- 
cantly upgraded KSC PRACA ADP capability to become operation- 
al in December 1983. This system could become an integral 
component of any proposed intercenter system. The functional 
capabilities to be provided will be determined within the 
s tudy . 

KSC will coordinate requirements definition and direct 
ADP system development while JSC, MSFC, VAFB, and KSC repre- 
sentatives provide requirements and review/approve specifica- 
tions. The direction of the intercenter PRACA system re- 
quirements development is stratified into two levels of guid- 
ance. The PRACA Working Group at KSC provides the direction 
for the KSC on-line ADP system development and advice for in— 
tercenter development methodology. A program-wide steering 
committee with representatives from each center regulates the 
course of NASA and USAF priorities and requirements for the 
intercenter PRACA ADP System. The Intercenter Steering Com- 
mittee reports to the Level II IMS Panel at JSC. 
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Various provisions have been made for monitoring the 
progress of the CSC software development team. The KSC PRACA 
Working Group as a whole or key representatives of the group 
meet with CSC weekly for joint working sessions to define re- 
quirements, or to name key field representatives for informa- 
tion gathering or to discuss organization, methodology, sta- 
us,or management of the project. There is also an informal 
status briefing for the KDMS Manager at his weekly user group 
meeting. At each major milestone in the CSC Digital Systems 
Development Methodology (see Figure 4) , a formal briefing is 
held for the KSC PRACA Working Group. On the inter center 
level, the informal status reports will be forwarded via the 
telemail feature of the JSC Office Automation System and 
through conference calls to MSFC and VAFB. The formal brief- 
ings will be delivered through the Kennedy Management Infor- 
mation System, KMIS, which enables viewgraphs to be transmit- 
ted to JSC, MSFC, and VAFB as the presentation is made through 
the conference call network. 


Reducing the cost of STS processing is a major program 
goal as we move into the fully operational era of two-week 
Shuttle turnaround. The centralized PRACAS serving KSC, 

VAFB, JSC and MSFC is projected to save time and money by re- 
ducing the existing manual interfaces and eliminating dupli- 
cate functions. A plan for tracking the cost benefits is in 
work at Level II. The budget expenditures for intercenter 
PRACAS are accounted for at KSC and will be combined with 
cost savings across centers to produce the bottom line cost 
reduction. Other significant cost savings might be realized 
if more complete and reliable data are available for analyzing 
failures. Failure analysis is often quite costly. The cen- 
tralized data base will provide more accurate up-to-date in- 
formation to support decisions for reducing the frequency of 
failure analysis. The same accurate up-to-date information 
will also support the total recurrence control function for 
increased STS reliability and cost effectiveness. 
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Figure 5-4 . 


PRACA ADP System Development. 
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Figure 5-5. Current Shuttle Problem Reporting Interfaces. 
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IV. CURRENT INTERCENTER PRACAS FUNCTIONS 


The day-to-day activities within the PRACA function are 
focused on the two broad areas of remedial action and cor- 
rective action. A remedial action can be an interim or final 
resolution to a nonconforming condition present in a system, 
an item, or a material. A corrective action which is direct- 
ed toward prevention of a recurrence of a nonconformance is 
synonymous with recurrence control. Failure analysis and/or 
redesign constitute corrective actions. 

At the program level, the remedial action function is 
preeminent at the launch centers (KSC/VAFB). Here the em- 
phasis is on expeditiously resolving nonconformances discov- 
ered during launch processing relative to flight-or launch/ 
flight-related equipment. If an identified nonconformance 
cannot be resolved or can be resolved on an interim basis 
only, a request for recurrence control is made. If it re- 
lates to ground support equipment, the request is transmitted 
to KSC Design Engineering. If it relates to flight hardware 
or software, it is transmitted to the local offices of the 
element contractors where it is then forwarded to their re- 
spective design engineering counterparts for action. 

Monitoring and statusing of corrective actions by the 
element contractors is the responsibility of the safety, re- 
liability, and quality assurance functions at JSC and MSFC. 

At JSC this responsibility includes the orbiter and govern- 
ment furnished equipment. At MSFC this includes the exter- 
nal tank, solid rocket booster, solid rocket motors, main en- 
gines, and inertial upper stage. The computer support at the 
two design centers varies. JSC utilizes a Control Data Cor- 
poration Cyber-74 computer for tracking and statusing open 
recurrence control problems at Rockwell International's Down- 
ey, California facility (orbiter) and at the various govern- 
ment furnished equipment vendor plants. MSFC utilizes an 
Alpha Micro Mini-computer to store the open problems at the 
Thiokol plant in Utah (solid rocket motor) , the Boeing plant in 
Kent, Washington (inertial upper stage), the Rocketdyne 
facility in Canoga Park, California (main engines), the USBI 
facility in Huntsville, Alabama (solid rocket boosters), and 
the Martin Marietta Corporation's Michoud Assembly Facility 
(MAF) in Mississippi (external tank). Both centers receive 
data from the contractors in their unique formats which are 
edited and reformatted into the NASA data bases at JSC and 
MSFC. Some data from the contractors is sent electronically 
through communication networks, but at present, is not 
directly connected to either NASA data base. Gleaning the 
NASA -required data from the contractor's reports is largely a 
manual function that is difficult to automate. Figure 5 por- 
trays the current program-wide interfaces. The data at the 
vendor sites is mostly computerized, utilizing vendor generat- 
ed software systems that support non-STS work at the plant. 
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The KSC PRACAS operates on a Honeywell DPS-8 computer. 
On-line status and tracking of open problems is provided 
through the Automated Scheduling System. Open recurrence 
control problems and historical data are stored in the PRACAS 
data base weekly from time sharing collector files built by 
the quality organizations. Various batch reports spawned 
weekly or on demand provide open problem lists for operations 
and maintenance functions and for recurrence control on 
ground support equipment. Other batch reports provide visi- 
bility into trends that consider location of the failure, 
failed part numbers, vendors/ and malfunction classifica- 
tions. Ad hoc reports are available by request with one-day 
turnaround. Figure 6 represents the current batch PRACAS. 
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V. THE PROPOSED KSC ON-LINE SYSTEM 


The KSC PRACAS requirements are defined and are currently 
in the review cycle. The intercenter requirements are gener- 
ally known but have not been fully analyzed and lack some de- 
tail. For these reasons, the KSC and intercenter system de- 
scriptions will be separated to provide for dissimilar levels 
of detail. The total integration of the KSC and intercenter 
requirements is planned, but the details are still in analy- 
sis. 

A. The KSC On-Line System 

The fully automated PRACA System depicted in Figure 7 
will greatly reduce the need for paper flow and will im- 
prove the action required response time of organizations 
processing the nonconformance. The identified noncon- 
formance will be entered into the PRACA data base imme- 
diately by a conveniently located terminal operator using 
easy forms mode. For inconvenient or restricted loca- 
tions such as white rooms, the data are transmitted to the 
terminal operator by telephone or head set. Automatic 
notification begins once the data are entered. Once the 
responsible engineering office is determined and noti- 
fied, the system will designate a qualified engineer to 
disposition the nonconformance. During troubleshooting, 
the engineer may require that certain steps from an Oper- 
ations and Maintenance Instruction (OMI) be used to 
troubleshoot/disposition the nonconformance. By stating 
the OMI number and steps involved, the PRACA System can 
obtain the information from the OMI data base and include 
it as part of the disposition block. Upon completion of 
the dispositon by the engineer, the quality organization 
identifies inspection points and if hazardous operations 
are involved, the safety organization identifies safety 
control. The work package will be completed with infor- 
mation obtained through the Automated Work Control System 
which will have interfaces to documented standard tasks, 
employee training and certification, configuration con- 
trol and logistics. The work package will be directed to 
the appropriate work station, worked by the assigned 
technician, closed through PRACAS with automatic termi- 
nation of the work control task accompanied by automatic 
notification of the appropriate personnel. If recurrence 
control is determined necessary, the appropriate design 
or sustaining engineering organization will be notified 
off site as well as at KSC. System security will provide 
for authorized approval and operations and maintenance 
statusing capability. If the problem report results in 
the generation of an Engineering Support Request, then 
the PRACAS will interface with the Modification Manage- 
ment System for tracking and statusing. 
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The fully automated PRACAS is an ambitious project 
depending on the future generation of automatic inter- 
faces between currently stand-alone Kennedy Data Manage- 
ment Systems ( KDMS ) , some on separate computers. Also, 
the intercenter requirements will not be fully defined 
until later this year. For these and other reasons, the 
implementation of PRACAS is defined as an initial phase 
(Phase I) and an open-ended continuation phase (Phase II) 
that must be correlated to the KDMS development cycle and 
revised to include intercenter requirements as they be- 
come available. 


B. The Optimum Data Study for the Intercenter System 

From the intercenter viewpoint, very generally, the 
objectives of the program are to track problems at the 
vendors that potentially impact missions and schedules, 
to track problems at the launch sites through remedial 
action, and to track all recurrence control failure analy- 
sis requests originating at the launch sites or the test 
facilities. The data and the structure of the flow of 
information is as follows. 

The launch sites, KSC and VAFB, track all nonconform- 
ance interim problem reports, discrepancy reports, and 
problem reports. These reports are written against 
ground support equipment, government furnished equipment, 
and flight hardware and software. The design centers, 

JSC and MSFC track only those problems that require fail- 
ure analysis for recurrence control. Ten percent of the 
problems at the launch sites require recurrence control 
with the remainder of requests for recurrence control 
originating at the test facilities. The recurrence con- 
trol for the ground support equipment is managed at KSC 
by the Design Engineering Directorate. The recurrence 
control for the orbiter and government furnished equip- 
ment is managed by JSC, and the recurrence control for 
the solid rocket motors, main engines, external tank, 
inertial upper stage, and solid rocket boosters is managed 
by MSFC. 

The information for tracking and statusing nonrecur- 
rence control failures at KSC and VAFB will be in the KSC 
central data base and will be worked from reports obtained 
directly from data by people who are located at the 
launch sites. Although JSC and MSFC and their contrac- 
tors require all of the data generated at KSC about prob- 
lems requiring recurrence control, the data generated by 
the design center contractors and by the NASA problem 
assessment centers is new data requiring data elements 
that are different from the KSC/VAFB data elements. The 
recurrence control functions at JSC and MSFC are worked 
by centralized problem assessment centers that manage 
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the recurrence control performed by the element and gov- 
ernment furnished equipment contractors and subcontract- 
ors. All problems that require recurrence control are of 
sufficient criticality to require detailed quality engi- 
neering assessment, detailed NASA engineering evaluation, 
and complete summary reporting to the responsible NASA 
management offices. It is not clear at this point in the 
intercenter PRACA requirements analysis whether some com- 
puterized data management should be provided at JSC and 
MSFC. The three choices for data base design are to have 
all data at KSC, provide for recurrence control data to 
be at JSC and MSFC, or to have the JSC recurrence control 
data at KSC and the MSFC recurrence control data at MSFC. 
Response time requirements, cost, and equipment avail- 
ability at the design centers will be major factors in 
these decisions. MSFC already has some mini-computer 
support but the JSC hardware support will be discontinued 
by next year. 

The KSC on-line system and the Optimum Data Study 
schedules are shown in Figures 8 and 9. The intercenter 
requirements, as defined in the Optimum Data Study, are 
subject to Level II approval prior to actual implementa- 
tion; therefore the schedule does not extend beyond the 
review cycle. 
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Figure 5-8. PRACA On-Line ADP System Development Schedule. 
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NOTES: /\ - Milestones 

P.R. - Progress Review Review 

I.T. - Integration Testing begins 


The number appearing next to the Milestone 
indicates the completion or review date. 


T. P.R. - Test Progress Review 

U. A.T. - User Acceptance Testing 


Figure 5-8. PRACA On-Line ADP System Development Schedule (Continued) 
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PROGRAM OBJECTIVES 


o To Support STS Operational ERA Turnaround Requirements. 
o To Reduce STS Processing Costs, 

APPROACH 

o Central Data Depository, 

o Accommodation Of Engineering Requirements, 

o Accommodation Of Reliability And Quality Assurance Requirements. 

Figure 5-10. Intercenter PRACAS . 
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Figure 5-11. Intercenter PRACAS-The PRACA Discipline. 


47 



Figure 5-12. 


PRACA Functional Perspective. 
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Figure 5-13. Uniform Closed Loop PRACAS. 
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1980 - NASA Headquarters Directed JSC To Study The PRACA Requirements For The 

STS Operational Era, 

1981 - Intercenter Meetings To Discuss Requirements. 

1982 - Evaluation Of Single Point Development Responsibility, 

o KSC Selected. 

- Reports All Nonconformances. 

- Transfers Shared Data. 

- Has Recurrence Control Responsibility For GSE At KSC And VAFB. 

Figure 5-14. Intercenter PRACAS-Background and Management. 


Responsibilities 

o KSC Coordinates Requirements Specification And Directs System Develop- 
ment. 

o JSC, VAFB, And KSC Provide Requirements And Review/Approve Specifica- 
tions. 

Direction 

o KSC PRACA Working Group/ Intercenter Steering Committee. 

- Coordinate Development Activities. 

- Review Progress. 

- Resolve Problems. 


Objective 

o Define A PRACA ADP System That Will Satisfy The Problem Reporting And 
Corrective Action Functions Common To All STS Program Centers With 
Emphasis On Operational Era Turnaround Objectives, Reliability, And Cost 
Effectiveness. 

Figure 5-14. Intercenter PRACAS-Background and Management (Continued). 
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Figure 5-15. PRACA ADP System Development. 


Remedial Action 

o Performed At Launch Centers (KSC/VAFB) . 

- KSC PRACAS Operates On Honeywell DPS-8 Coiputer. 

, Open Problems - On-Line Status Provided By Scheduling System. 

. Closed Problems - Batch Updating And Reporting. 

Corrective Action 

o Performed At Design Centers (JSC/MSFC). 

MSFC PRACAS Operates On Alpha Micro Mini-Computer. 

- Well-Developed Centralized Problem Assessment Center. 

. Contractor Corrective Action Reports Sent to MSFC By Mail, Datafax, 
Or Communications Network. 

. MSFC Manually Gleans NASA Required Data From Contractor's Reports. 

- JSC PRACAS Operates On CDC Cyber-74 Computer. 

. Centralized Problem Assessment Center. 

- Very Similar In Function To The MSFC Problem Assessment Center. 

- Plans To Phase Out The CDC Cyber-74 Computer Support. 


Figure 5-16. Intercenter PRACAS -Current Intercenter PRACAS 

Functions. 
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M - MANUAL (MAIL, TELEPHONE, DATAFAX) 

SA - SEMI-AUTOMATIC (MANUAL INPUT TO COMPUTER! 

Figure 5-17. Current Problem Reporting Interfaces. 


o PRACA Is Essential In The STS Ops Era At KSC/VAFB, 
o Current Batch PRACAS Must Be Upgraded To Meet Ops Era Requirements. 

o A Fully Automated PRACAS Has Been Defined To Meet KSC Requirements, 

- Fully Automated System Constraints. 

. Budgets. 

. KDMS Development Cycle. 

. Shuttle Processing Contractor. 

- Two-Phased Implementation. 

. Phase I - Major Upgrade To KSC PRACAS By December 1983, 

. Phase II - Open-Ended Enhancements To Phase I Configuration, 

Figure 5-18. Intercenter PRACAS-Proposed KSC On-Line System. 
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o Examine PRACA Requirements At A Program Level, 

- Site Visits to JSC, MSFC,And VAFB Complete. 

- All Centers To Review And Resolve Differences At KSC June 1 And 2. 

o Specify PRACA Capabilities That Support All Four Centers. 

- Consider Ops Era Turnaround Requirements. 

- Consider Reliability. 

- Consider Cost. 

o Evaluate And Adopt Most Cost-Effective Strategy, 

- Utilize Existing Hardware Where Possible. 

- Integrate System Interfaces, 

o Options. 

- Data Base At KSC With Remote Terminal/Printer Access. 

- Central Data Base At KSC With Recurrence Control Data Bases At MSFC And 
JSC. 

- Central Data Base At KSC To Serve KSC, VAFB, And JSC; Recurrence Control 
Data Base At MSFC. 

Figure 5-19. Intercenter PRACAS-Proposed Intercenter PRACAS . 


o On-Line Data Entry, Update, And Retrieval. 
o User Friendly. 

o Flexible Report Generation. 

o Modular Design, 

o Contingency Recovery, 

o System Control. 

o Statistical Analysis Applications Software. 

o Forms Mode Entry, 

o Help Function, 

o On-Line Edit. 

o Interactive Search And Retrieval. 

o Management Information Reports, 

o Automatic Interface With KDMS, 

o Effective Constraints Control, 

o Automatic Notification, 

o Minimal Use Of Paper. 


Figure 5-20. Intercenter PRACAS-System Capabilities. 
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REQUIREMENTS SPECIFICATION 


DESIGN 


REVIEW/ACCEPT 


KSC ON-LINE SYSTEM 


REQUIREMENTS SPECIFICATION 


DESIGN 


SOFTWARE CONSTRUCTION 


TEST & EVALUATION 


ACCEPTANCE 


JAN 1 FEB 1 MAR 1 APR 1 MAY 1 JUN 1 JUL 1 AUG 1 SEP 1 OCT 1 NOV 1 DEC 1 JAN 
1983 l 984 

INTERCENTER SCHEDULE 

Figure 5-21. Optimum Data System Study. 
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6. INTEGRATING MICRO-COMPUTERS WITH A CENTRALIZED 
DBMS: ORACLE, SEED, & INGRES 


Jerry Hoerger 

Planning Research Corporation 
Langley Research Center, 
ABSTRACT VA 


Approx i mate 3. y three years ago, BDSD installed a relational-like 
data base management system (ADABAS) and a data base programming 
language (NATURAL). The primary goals? such as controlled 
redundancy of data elements, data independence, increased system 
development product i vi ty , the ability to share data among 
organizational units, and easy access to the data by our end users 
art? being realized. Today many of our users are acquiring micro- 
computers with hopes of solving their individual word processing, 
office automation, decision support, and simple data processing 
problems. As processor speeds, memory sizes, and disk storage 
capacities increase, individual departments will begin to maintain 
"their own" data base on "their own" micro-computer. This situation 
will adversely affect, several of the primary goals we set f or 
implementing a centralized DBMS. Redundant data elements will 
appear in several different micros, and data will not be sharable 
a m o n g or g a nizatio n a 1 u n i t s . 

In order to avoid this potential problem we must integrate 
these mi cro— computers with our centralized DBMS. We must provide 
an easy to use and flexible means for transferring logical data base 
files between the central data base machine and micro-computers. 

This paper discusses some of the problems BDSD has encountered in an 
effort to accomplish this integration and how we hope to solve them. 

BDSD SYSTEM CONFIGURATION 


BDSD’s mainframe consists of an 8 megabyte IBM 4341 model 
group 2 processor, 16 Memorex 3350 disk drives, 8 STC tape 
drives, and IBM unit record equipment. The communications network 
is made up of a Memorex 1270 transmission control unit, an IBM 3705 
communications controller, a variety of IBM 3270 compatible terminals, 
and a mixture of TWX 33/35 compatible teletype terminals. The 
operating system is MVS/SP with JES2. Software a g ’ s data base 
management system (ADABAS), system development and query language 
(NATURAL), and teleprocessing monitor (COM-PLETE) are used to 
provide on-line access to our centralized data base. 

The ADABAS data model is essentially a relational model. 

Files in the data base are defined independently, and rel ati onshi ps 
between the files are based on fields which exist within the files. 

For example, a customer /or der file relationship could be defined 
by maintaining the customer number field in both the customer and 
order files. Within each file maximum of 200 fields can be defined 
as descriptors (keys) . A logical data base file can be accessed 
by using several descriptor values in Boolean combination. 

This architecture enables us to view the data as independent flat 
files, as hierarchies of files, or as a network of files. 
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NATURAL is an interactive development language designed 
for use with ADABAS. It is a procedural language composed of 
BASIC and COBOL-like syntax. It is particularly useful in the 
development of structured programs and does reduce program development 
time substantially. A subset of NATURAL forms the ADABAS report 
writer and on-line query facility. This is used by our end users to 
prepare their own reports and on-line queries. 

BACKGROUND 


Approximately one year ago we began providing formal ADABAS 
and NATURAL training seminars for all users in our directorate. 
Managerial, professional, clerical, and secretarial personnel from 
all divisions have attended these seminars. Since we began these 
seminars our user base has increased three-fold, and information 
needs have become more diversified. Managers want graphics, professiona 
want to be able to create and maintain their own data base files, 
clerks want more systems automated, and secretaries want word processing 
and electronic mail. As with any large system the complexities of the 
centralised DBMS are causing it to become a bottleneck to meeting these 
disparate needs. The micro-computer on the other hand can solve these 
problems very easily (if you believe everything you read) provided 
you can access the centralised DBMS to get the data needed to 
produce the graph, use with the spreadsheet package, build the data 
base, or to merge with the form letter. 


THE FIRST ENCOUNTER 


Our first encounter with a micro-computer came from the training 
section of personnel. They wanted to maintain class schedules and 
attendant lists on a data base and merge this data with a word processin 
package to produce personalized correspondence for the attendants. Other 
requirements were to download the addresses of attendants from the 
personnel file on ADABAS, to transmit batched data files between ADABAS 
and the micro, and to emulate an IBM 3270 terminal for i nteract i vel y 
updating attendants personnel records maintained in ADAEiAS. 

A XEROX S20-II micro-computer was leased from a local third party 
vendor. It looked as though it could solve all of these requirements 
with very little assistance from the data processing staff. The system 
consisted of the following components: 

HARDWARE 

Z80 micro-processor 

64k random access memory 

letter quality printer 

(1) 3" floppy disk drive 

(1) 10 megabyte hard disk drive 

keyboard and monochrome display 

synchronous communications adapter 
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SOFTWARE 


CF‘/M - operating system 
DE-iASE-II - data base manager 
WORDSTAR - word processing package 
QUICKCODE - data base programming language 
E-ISC3270 - IBM3270 terminal emulator 
BSC3780 - IBM3780 data communications terminal 
emul ator 

A 30 -day acceptance period was established in which time the hardware 
and software would be installed and evaluated. The vendor was to be 
responsible for installing, training, and maintaining all hardware 
and software components of the system. 

After the initial installation, training was to begin on the use 
of WORDSTAR. This was to begin immediately, but due to unknown sources 
of hardware problems it was delayed three weeks. During this time I 
was trying to install the BSC3270 emulator. As with the training, this 
process was delayed due to hardware problems. By the time the hardware 
problems were resolved, we were well into our fourth week of the acceptance 
period so we extended it by four more weeks. 

Once the original hardware problems were resolved, training on 
WORDSTAR began, and it seemed to satisfy the word processing 
requirements. After several conversations with the vendor we acquired 
the BSC3270 software from XEROX, Integrated Systems, Inc., and IE Modem 
I finally managed to get the emulator installed and started testing it. 

The first problem that surfaced was the inability to communicate 
at speeds greater than 2400bps. It soon became apparent that the 
synchronous communications adapter on the XEROX was much more sensitive 
to signal distortion than a regular terminal controller. After spending 
a good deal of time adjusting the equalisation on the modems, I was able 
to communicate at 9600bps. The next and final problem was that the 
BSC3270 emulator would lose synchroni sati on with the host teleprocessing 
monitor. Neither of the four vendors laying claim to the software 
could or would solve this problem. 

Our extended trial period was about over, so we elected to 
return the system to the vendor. Neither DBASE-II nor QUICKCODE were 
installed but after looking at the documentation training, we felt that 
they would meet their data base management requirements. 

THE SECOND ENCOUNTER 


The second encounter with a micro-computer came from the Financial 
Management Division. I'm not exactly sure what the application was but 
one of the requirements was to download a logical ADABAS file and convert 
it to a data base file on the micro. 
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An IBM-F'C was purchased -from a local computer store and was 
configured as follows: 

HARDWARE 

Intel 8088 processor 
64k random access memory 
matrix printer 

(2) 5 1/4" floppy disk drives 
keyboard and monochrome display 
asynchronous communications adapter 

SOFTWARE 

DOS 1.1 - operating system 
T.I.M. - data base manager 
asynchronous communications support - 
teletype terminal emulator 

The installation of the software and hardware was accomplished 
by personnel in the Financial Management Division. I assisted them 
in installing and configuring the asynchronous communication support 
package. Within a week they were using the data base manager and 
wanted to start downloading a logical ADABAS file to the IBM-PC. 

The asynchronous communications support package allows you to 
interactively configure the communications adapter and emulator to 
match the protocol supported by the host teleprocessing monitor. 
Options such as using X0N/X0FF characters to start and stop 
transmission, selecting a message termination character (XOFF, CR, 
EOT, etc.), setting the transmission speed, and others are 
selectable from a menu. Within a few minutes we were able to 
communicate with ADABAS via NATURAL and with a stroke of a key 
could record the data coming from the communications adapter on 
a diskette on the micro. 

A utility program provided by the T.I.M. data base manager was 
then used to convert the transmitted file to a T.I.M. data base file. 
Unfortunately, the file we transmitted was not in the exact ASCII 
format required, and several noise records were cluttering the file. 
Once we determined the ASCII file format required we manually 
edited the file a record at a time and eventually got it into the 
ASCII format needed. The edited file was then processed by the 
conversion utility, and a T.I.M. data base file was built from a 
logical ADABAS file. 

The primary requirement for downloading a logical ADABAS file 
was accomplished; however, it would have been easier if we had 
manually entered the data directly from the keyboard. 
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ESTABLISHING COMMUNICATION STANDARDS 


Since the -first two requests for transmitting logical ADABAS 
files to a micro computer, I have heard from three other sections 
concerning the same problem. The Programs and Resources Division, 
the Acquisitions Division, and the Office of Director for Management 
Operations have requested similar capabilities. Given the problems 
associated with the first two attempts, we decided it was time to 
establish some standard modes of communication that BDSD would 
support . 

MODES OF COMMUNICATION 


Currently, BDSD can support the following modes of communication 
between the centralised data base and a mi cro -computer : 

(1) Emulation of an IBM 3270, IBM 3101, 
and TWX 33/35 teletype terminals 

(2) Interactive selection and transmission 
of logical ADABAS files via NATURAL 

(3) Batch transmission of data files via 
JESC’s remote job entry subsystem 

The remainder of this paper discusses how these modes of communication 
are used, problems associated with them, and what future developments 
are required to successfully integrate the mi cro -computer with our 
centralized data base management system. 

TERMINAL EMULATION 


IBM 3270 EMULATION 

The IBM 3270 emulator should be used when a high volume of 
on-line queries, reporting, or transactional processing is required. 

A synchronous communications adapter is needed on the micro and 
should support transmission speeds up to 9600bps. The ability to 
coexist with other IBM 3270 terminals on a multipoint line is 
also desirable. 

The primary problem associated with emulating an IBM 3270 terminal 
is that of maintaining synchronization with the host teleprocessing 
monitor. The Binary Synchronous Communications (BSC) protocol is used 
for communicating with an IBM 3270 terminal. This protocol uses a 
polling technique to determine if a terminal has data ready to send. 
Whether it does or not, a response must be sent to the host 
communications controller within a few seconds or a time out condition 
will occur. Our teleprocessing monitor (C0M-PLETE) will ignore a 
terminal for a minimum of 10 seconds after the 3rd consecutive time 
out. If the emulator is started during this time it will lose 
synchroni zat i on with COM— F'LETE. Manual intervention by the host 
network operator is required at this point, and the emulator will 
have to be restarted. 
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IBM 3101 EMULATION 


The IBM 3101 terminal emulator should be used -for low-volume 
queries, reporting, and transactional processing. An asynchronous 
communications adapter is required on the micro and should support 
transmission speeds up to 1200bps. This terminal can operate in a 
mode similar to the IBM 3270 as well as a line-oriented teletype 
terminal. In the block mode it supports -full screen f ormatt i ng, and 
many of the applications designed for the IBM 3270 can be used. 

The primary problem associated with this emulator is that it uses 
an asynchronous communications protocol . This limits the transmission 
speed to a max i mum of 1200bps. Also, error detection is limited to 
parity checking on a character by character basis. 

TWX 33/35 TELETYPE EMULATION 

The teletype emulator should be used -for low-volume queries and 
reporting. An asynchronous communications adapter is required on the 
micro and should support transmission speeds up to 1200bps. 

As with the IBM 3101 emulator, the primary problem with this 
emulator is that it uses an asynchronous communications protocol . It 
does not s;upp or t full screen formatting and cannot be used with 
applications specifically designed for the IBM 3270. 

INTERACTIVE FILE TRANSMISSION 


This mode of communication is used for i nteract i vel y selecting 
and transmitting a logical ADABAS file to a micro-computer. An 
asynchronous terminal emulator is used for handling the communications, 
NATURAL is used for selecting and formatting the file to be transmitted 
and a utility program on the micro converts the file to a standard 
ASCII format. The ASCII formatted file seems to be the most commonly 
used file type on the micro. It is directly accessible by BASIC and 
most software packages provide utilities for converting them to other 
formats as needed. 

Most asynchronous communication emulators support two modes of 
operation: one for emulating a teletype terminal and the other for 
capturing the incoming data on a disk file as well as the display. 

Both of these modes, in conjunction with NATURAL, are used to select 
and transmit a logical ADABAS file to a file on the micro. While in 
terminal mode, a NATURAL program is coded to select the desired logical 
ADABAS file to be transmitted. The only difference in a NATURAL progra 
used for transmitting a file versus performing a query is the way 
literal strings are formatted and the write statement used to send a 
record to the terminal. In a standard query program the data is 
formatted in a report format. Fields are aligned on the display and 
column headings are added. When transmitting a file, we do not want 
the fields aligned nor do we want column headings included in the data. 
After the program is coded, the emulator is set to the file capture 
mode and the program is executed. 
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A sample NATURAL program and the -format of the record transmitted is 
illustrated below: 


-NATURAL PROGRAM- 

RESET #NAME (A26) 

RESET ttQUOTE (Al) 

(1) ASSIGN ttQUOTE = H’TF’ 

FIND PERSONNEL WITH CLASS-CODE = 'C400' THRU ’CttS?’ 

(2) COMPRESS ttQUOTE NAME ttQUOTE INTO ttNAME LEAVING NO SPACE 

(3) WRITE NOTITLE NOHDR CLASS-CODE EMPLOYEE-NO ttNAME 
END 

(1) A hexadecimal value of ? 7 F J is the EBCDIC representation 
of a quote mark. Each literal string containing a blank 
or comma must be enclosed in quotation marks. 

(2) The compress statement is used to form a literal string 
enclosed in quotation marks. This is required because 
commas and blanks are included in the value of the name 
field on the data base. 

(3) The write statement causes a record to be written to the 
termi nal . 

-TRANSMITTED RECORD FORMAT- 

cl ass-cod eBempl oyee-noB" 1 ast-name, f i rst-name"CRLF 

Each field is separated by at least one blank, identified 
by a capital "B" above, and each record is terminated with 
a carriage return (CR) and line feed (LF) character. 

When the file transmission is complete a utility program on the 
micro removes noise records and converts the transmitted file to the 
following standard ASCII format: 

-STANDARD ASCII FORMAT- 

cl ass-code, ernpl oyee-no, " 1 ast-name, f i rst-name"CRLF 

The only difference between the transmitted file and the 
ASCII file format is that all the blanks separating the 
fields have been removed and/or replaced with commas. 

The main problems associated with this mode of communication 
are directly attributable to the asynchronous communications protocol . 
As with the asynchronous terminal emulators, the maximum reliable 
transmission speed is 1200bps, and error detection is limited to parity 
checking on a character by character basis. 
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BATCHED FILE TRANSMISSION 


This mode o-f communi cat i on supports the transmission of files 
between the central data base and a mi cro -computer . It can be used 
for transmitting transact i anal data used for updating the central 
data base in batch mode. A synchronous communications adapter is 
required on the micro and should support transmission speeds up to 
9600bps. 

The remote job entry subsystem of JES2 is used to facilitate the 
communications process on the host computer and an IBM 3780/2780 
emulator is used on the micro. Files are processed in batch mode on 
the host and are transmitted as 80 byte punched-card images. 

The major problem with this mode of communi cat i on is that it 
is restricted to the batch mode and custom programs must be written 
to process the files. Another shortcoming is the limitation of 
only being able to transmit 80 byte punched-card images. 

FUTURE DEVELOPMENTS 


Many of the mainframe software vendors are beginning to provide 
software for mi cro -computers which will allow them to interface 
directly with their host counterparts. Cullinet, Inc., ISCC0, Inc., 
and SAS Institute, Inc. have recently announced IBM-PC interfaces to 
their mainframe data base and graphics software. Software ag has 
hinted at providing a similar interface for ADABAS. 

IBM has announced an IBM 3278 hardware attachment and associated 
terminal emulation software that will allow the IBM-PC to be directly 
connected to an IBM 3274 terminal controller. A similar feature is 
available for the IBM DISPLAY WRITER. 

Many small software companies will provide general purpose 
communications software packages that will allow users to connect 
their unique data base files via user- wr i tten exit programs. This 
is currently being done for interfacing mc\ny of the popular data 
base management systems with a variety of business application packages 

At any rate, given the current state-of -the-art , things can only 
get better. 
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IBM m. MODEL GROUP 2 PROCESSOR 


0 

o 

0 

• 

0 

Figure 


0 

Figure 


8 MEGABYTE MEMORY 

16 MEMOREX 3350 DISK DRIVES 

8 STC TAPE DRIVES 

IBM UNIT RECORD EQUIPMENT 

MEMOREX 1270 TRANSMISSION CONTROL UNIT AND 
IBM 3705 COMMUNICATIONS CONTROLLER 

VARIOUS IBM 3270 COMPATIBLE TERMINALS 

MIXTURE OF TVJX 33/35 COMPATIBLE TELETYPE TERMINALS 

6-1. BDSD Hardware Configuration. 


WS/SP OPERATING SYSTEM WITH JES2 

ADABAS - DATA BASE MANAGEMENT SYSTEM - 
SOFTWARE AG 


NATURAL - DEVELOPMENT AND QUERY LANGUAGE - 
SOFTWARE AG 

COMPLETE - TELEPROCESSING MONITOR - 
SOFTWARE AG 


6-2. BDSD Software Configuration. 
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INVERTED LIST STRUCTURE 


• SUPPORTS RELATIONAL, HIERARCHICAL OR 
NETWORK MODELS 

o 255 FILES PER DATA BASE 

0 200 DESCRIPTORS (KEYS) PER FILE 

# RELATIONSHIPS BETWEEN FILES ARE BASED 
ON FIELDS WITHIN THE FILES 


Figure 6-3. ADABAS Architecture. 


0 INTERACTIVE PROGRAM DEVELOPMENT LANGUAGE 

o PROCEDURAL WITH MIXTURE OF BASIC AND COBOL SYNTAX 

o SUBSET PROVIDES END USER REPORT WRITING AND 
ON-LINE QUERY CAPABILITIES 


Figure 6-4. Natural Language. 
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• CONTROLLED REDUNDANCY OF DATA ELEMENTS 

• DATA INDEPENDENCE 

• INCREASED SYSTEM DEVELOPMENT PRODUCTIVITY 

• ABILITY TO SHARE DATA AMONG ORGANIZATIONAL UNITS 

• EASY ACCESS BY OUR "END USERS" 


Figure 6-5. Centralized DBMS Objectives. 


• FORMAL ADABAS/NATURAL TRAINING SEMINARS 

• MANAGEMENT, PROFESSIONALS, CLERICAL AND 
SECRETARIAL PERSONNEL (250 USERS) 

e TRAINING HAS PRODUCED NEW REQUIREMENTS 

• GRAPHICS 

• WORD PROCESSING 

o DYNAMIC DEFINITION AND CREATION OF 
DATA BASE FILES 

Figure 6-6. Expanded User Community. 
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• CONTROL SOMETIMES PROHIBITS FLEXIBILITY 

o COMPLEXITY DEMOS DATA PROCESSING SPECIALISTS 
» DEVELOPMENT TIME IS STILL A BOTTLENECK 

• SOFTWARE MUST INTERFACE TO THE DBMS 


Figure 6-7. Problems Associated with a Centralized DBMS. 

e NO CONTROL REQUIRED 

• MANY WORD PROCESSING, DECISION SUPPORT, GRAPHICS, 

AND DATA BASE MANAGEMENT PACKAGES 

o SIMPLICITY DOES NOT REQUIRE DATA PROCESSING SPECIALIST 

o APPLICATIONS CAN BE DONE BY THE END USER 


Figure 6-8. The Micro Computer Solution. 
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TRAINING SECTION OF PERSONNEL 

MAINTAIN CLASS SCHEDULES AND ATTENDANT 
LISTS ON A DATA BASE 

PERGE DATA BASE FILES WITH A WORD PROCESSING 
PACKAGE TO PRODUCE PERSONALIZED CORRESPONDENCE 
FOR ATTENDANTS 

DOWNLOAD ATTENDANT ADDRESSES FROM THE CENTRAL 
PERSONNEL FILE MAINTAINED ON ADABAS TO TTE DATA 
BASE ON THE MICRO 

EMULATE AN IBM 3270 TERMINAL FOR INTERACTIVELY 
UPDATING ATTENDANTS PERSONNEL RECORDS MAINTAINED 
ON ADABAS 


6-9. The First Encounter. 


HARDWARE . 

XEROX 820-11 MICRO COfWIER 
64K RANDOM ACCESS MEMORY 
LETTER QUALITY PRINTER 
•CL) 8" FLOPPY DISK DRIVE 
(1) 10 MEGABYTE HARD DISK DRIVE 
KEYBOARD AND MONOCHROME DISPLAY 
SYNCHRONOUS COf T-UNICATIONS ADAPTER 


SOFTWARE 

CP/M - OPERATING SYSTEM 
EBASE-II - DATA BASE MANAGER 
WORDSTAR - WORD PROCESSING PACKAGE 
QUICKCDDE - DATA BASE PROGRAMING LANGUAGE 
BSC3270 - IBM 3270 TERMINAL EMULATOR 
BSC3780 - IBM 3780 DATA COmiMCATIONS TERMINAL 
EMULATOR 


6-10. Micro System Configuration. 
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INITIAL UNKNOWN HAREWARE PROBLEMS 


o LACK OF SKILLED TRAINER 

• INABILITY TO COfTUNICATE AT SPEEDS GREATER 
THAN 2400 BPS 

• (JOSS OF SYNCHRONIZATION WITH HOST TELEPROCESSING 
MONITOR 

o PROBLEM RESOLUTION WAS NEVER ACCOMPLISHED 


Figure 6-11. Problems Encountered. 


• FINANCIAL MANAGEW DIVISION 

e CREATE AND MAINTAIN A DATA BASE FILE CONTAINING 
FINANCIAL DATA NOT MAINTAINED ON ADABAS 

• DOWNLOAD A PORTION OF THE FINANCIAL FILE 
MAINTAINED ON ADABAS TO THE DATA BASE ON 
THE MICRO 

o MERGE THE TWO FILES FOR REPORTING 


Figure 6-12. The Second Encounter. 
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• HARDWARE 


IBM-PC MICRO COMPUTER 
64K RANDOM ACCESS MEMORY 
MATRIX PRINTER 
(2) FLOPPY DISK DRIVES 
KEYBOARD AND MONOCHROME DISPLAY 
ASYNCHRONOUS COmUNICATIONS ADAPTER 

o SOFTWARE 

DOS 1.1 - OPERATING SYSTEM 
T. I. M, - DATA BASE MANAGER 
ASYNCHRONOUS COMMUNICATIONS SUPPORT - 
TELETYPE TERMINAL EMULATOR 

Figure 6-13. Micro System Configuration. 


o CONVERSION OF THE DOWNLOADED ADABAS FILE 
COULD NOT BE ACCOMPLISHED BECAUSE IT WAS 
NOT IN THE APPROPRIATE FORMAT FOR THE 
T. I. M. CONVERSION UTILITY 

• MANUAL EDITING OF THE DOWNLOADED FILE 
WAS REQUIRED 


Figure 6-14. Problems Encountered. 
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0 


EMULATION OF IBM 3270, IBM 3101, AND M 33/35 
TELETYPE TERMINALS 

• INTERACTIVE SELECTION AND TRANSMISSION OF 
LOGICAL ADABAS FILES VIA NATURAL 

0 BATCH TRANSMISSION OF TEXT AND/OR DATA FILES 
VIA JES2'S REMOTE JOB ENTRY SUBSYSTEM 


Figure 6-15. Standard Modes of Communication. 


0 USED FOR HIGH VOLUTE QUERIES, REPORTING, 

AND BDSD DEVELOPED FILE MAINTENANCE SYSTEMS 

0 BINARY SYNCHRONOUS COM CATIONS PROTOCOL 

0 TRANSMISSION SPEEDS OF 2400 TO 9600 BPS 

0 FULL SCREEN FORMATTING CAPABILITY 


Figure 6-16. IBM 3270 Emulation. 
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s USED FOR LCW VO UUME INTERACTIVE QUERIES, 
REPORTING, AND BDSD DEVELOPED FILE 
MAINTENANCE SYSTEMS 

e ASYNCHRONOUS COfT‘1UNI CATIONS PROTOCOL 
o TRANSMISSION SPEEDS OF 300 TO 1200 BPS 
• FULL SCREEN FORMATTING CAPABILITY 


Figure 6-17. IBM 3101 Emulation. 


• USED FOR LOW V0L1ME QUERIES AND REPORTING 

• ASYNCHRONOUS COmUNICATIONS PROTOCOL 

• TRANSMISSION SPEEDS OF 300 TO 1200 BPS 


Figure 6-18. TWX 33/35 Emulation. 
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• USED FOR INTERACTIVELY SELECTING AND TRANSMITTING 
LOGICAL ADABAS FILES TO IDE MICRO 

• ASYNCHRONOUS TERMINAL EMULATOR USED FOR 
HANDLING COfTONICATIONS 

o NATURAL IS USED FOR SELECTING AND FORMATTING 
THE LOGICAL ADABAS FILE TO BE TRANSMITTED 

• UTILITY PROGRAM ON THE MICRO IS USED TO CONVERT 
THE TRANSMITTED FILE TO A STANDARD ASCII FORMAT 

Figure 6-19. Interactive File Transmission. 

RESET am£ (A26) 

RESET #QUOTE (Al) 

(1) ASSIGN #QUOTE = H'7F' 

FIND PERSONNEL WITH CLASS-CODE = 'CW THRU 'CA99' 

(2) COMPRESS #QUOTE NAME #QUOTE INTO m E 
LEAVING NO SPACE 

6) WRITE NOTITLE NOHDR CLASS-CODE ETPUDYEE-NO #NAME 
END 

(1) EACH LITERAL STRING CONTAINING A COMMA MUST BE 
ENCLOSED WITHIN QUOTATION MARKS. (H'7F # = ") 

(2) THE CONFESS STATEMENT IS USED TO ENCLOSE THE 
DATA BASE FIELD NAME IN QUOTATION MARKS. 

(3) THE WRITE STATEMENT CAUSES THE RECORD TO BE 
WRITTEN TO THE COTTON I CATIONS LINE. 

Figure 6-20. Natural Program. 


72 



CUSS-CODE B EMPLOYEE-NO B "LAST-NAME, FIRST-NAME" CRLF 


• EACH FIELD IS SEPARATED BY A BLANK 

• EACH RECORD IS TERMINATED BY A CARRIAGE 
RETURN (CR) AND LINE FEED (LF) CHARACTER 


Figure 6-21. Transmitted Record Format. 


CLASS-CODE, EMPLOYE-NO, "LAST-N/ME, FIRST-NAME" CRE 

• UTILITY PROGRAM ON THE MICRO CONVERTS IDE 
TRANSMITTED FIE TO IKE STANDARD ASCII FORMAT 

• ASCII FORMAT IS ACCESSIBE BY BASIC 

• MANY MICRO SOFTWARE PACKAGES PROVIDE UTILITIES 
FOR CONVERTING ASCII FIES TO FORMATS REQUIRED 


Figure 6-22. Standard ASCII Format. 



• USED FOR TRANSMITTING DATA/TEXT FILES BETWEEN 
THE CENTRAL DIMS AND A MICRO COMPUTER 

o IBM 2780 TERMINAL EMULATOR AND JES2'S REMOTE 
JOB ENTRY SYSTEM HANDLE COMMUNICATIONS 

• THE FILE TO BE TRANSMITTED IS CREATED AND 
ROUTED TO TIE MICRO IN BATCH 

• TEXT FILES ARE TRANSMITTED AS 80 BYTE 
PUNCHED-CARD IMAGES 

• DATA FILES ARE TRANSMITTED AS 132 CHARACTER 
PRINT IMAGES 

Figure 6-23. Batched File Transmission. 

• MAINFfWE SOFTWARE VENDORS WILL PROVIDE 
SOFTWARE TO DIRECTLY LINK THE MICRO WITH 
THEIR HOST COUNTERPARTS, (CULLINET, INC., 

1SSC0, INC,, SAS INSTITUTE, INC.) 

• IBM-PC CAN BE ATTACHED DIRECTLY TO AN 
IBM 3274 CONTROLLER. 

• SMALL SOFTWARE CCFPANIES WILL PROVIDE GENERAL 
PURPOSE ALLOWING ACCESS TO A VARIETY OF DATA BASES. 

• APPLICATION DEVELOPMENT WILL EXTEND TO THE MICRO. 

• END USER COmJNITY WILL BE THE DRIVING FORCE. 

Figure 6-24. Future Developments. 
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QUANTITATIVE EVALUATION OF THREE DBMS: ORACLE, SEED, & INGRES 


Regina Sylto 

Goddard Space Flight Center 



0 NASA SCIENTIFIC DATA BASE MANAGEMENT APPLICATIONS 


0 PERFORMANCE TESTING OBJECTIVES 
0 SAMPLE OF PERFORMANCE TESTING RESULTS 
0 CONCLUSION 


Figure 7-1. Presentation Outline. 


CHARACTERISTICS ; 

0 LARGE AMOUNTS OF SCIENTIFIC INFORMATION MUST BE MANAGED. 

0 CURRENTLY, MOSTLY META- INFORMATIONAL DATA ABOUT SCIENTIFIC DATA 
SETS IS MANAGED. 

0 CHANGES ARE NOT MADE FREQUENTLY TO THE META-INFORMATION. 

DBMS REQUIREMENTS ; 

0 EMPHASIS ON LOAD AND ACCESS OF DATA 
0 DE-EMPHASIS ON UPDATING AND DELETING OF DATA 
EX A MP LES; 

0 PILOT CLIMATE DATA BASE MANAGEMENT SYSTEM (PCDBMS) 

0 CRUSTAL DYNANICS/DIS 
0 LANDSAT A/SIS 

0 PACKET MANAGEMENT SYSTEM (PMS) 

Figure 7-2. NASA Scientific Data Base Management Applications. 
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FIRST LEVEL (FY81 ): 

0 TO ASSESS CAPABILITIES OF DATA BASE MANAGEMENT SYSTEMS (DBMS) TO MANAGE 
LARGE AMOUNTS OF DATA (AT LEAST 1 MILLION INPUT RECORDS PER APPLICATION, 
130 MEGABYTES) 

0 TO DETERMINE DATA BASE LOAD RATES 

0 TO MEASURE THE EFFICIENCY OF VARIOUS DATA ACCESS TECHNIQUES USED IN 
THE DBMS PACKAGES 

0 TO EVALUATE QUALITATIVE CHARACTERISTICS 
SFCOND IFVFI. (FY82 - FYB3) : 

0 TO DETERMINE THE EFFECTS OF VARYING THE FOLLOWING FACTORS: 

INTERNAL DBMS PARAMETERS: 

- FIELD SIZE, NO. OF FIELDS, FIELD TYPES 

- NO. OF KEYS, KEY LENGTH, DUPLICATION OF KEY VALUES 
EXTERNAL DBMS PARAMETERS: 

- NUMBER OF USERS (1-15) (DBMS AND VAX) 

- DBMS AND VAX/VMS OPERATING SYSTEM PARAMETERS 

0 TO PROVIDE A BASIS FOR PREDICTING THE EFFECT OF VARIOUS DB DESIGNS 
0 TO PROVIDE A BASIS FOR DBMS SELECTION 


Figure 7-3. Performance Testing Objectives. 


ORACLE: 

0 MARKETED BY ORACLE CORPORATION (1980) 

0 RELATIONAL MODEL 
0 275 INSTALLATIONS 

SEED: 

0 MARKETED BY SEED SOFTWARE INCORPORATED (1979) 

0 NETWORK MODEL 
0 107 INSTALLATIONS 

RIM: 

0 NASA/LaRC 1 N-HOUSE PRODUCT (1980), MARKETED BY BOEING (1982) 
0 RELATIONAL MODEL 
0 ? INSTALLATIONS 
INGRES: 

0 HARKETED BY RELATIONAL TECHNOLOGY INC. (1981) 

0 RELATIONAL MODEL 
0 210 INSTALLATIONS 


Figure 7-4. DBMS Packages. 
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ORACLE 

SEED 

RIM 

SENSITIVITY 
OF LOAD RATES 
TO DB SIZE 

FAIRLY CONSTANT 
FOR ALL SIZE 
DATA BASES 

LARGE DEGRADATION 
AS DB SIZE 
INCREASES 

STABILIZES AS 
DB SIZE 
INCREASES 

USER OPTIONS TO 
IMPROVE LOAD RATES 

LITTLE 

FLEXIBILITY 

MANY OPTIONS 
(HASH, DIRECT) 

LITTLE 

FLEXIBILITY 

QUERY RATES 
WITH INDEXED 
SEARCH 

* * * ALL SYSTEMS ACCEPTABLE AT ALL SIZES (5K - 

1M RECORDS) * * * 

QUERY RATES 
WITH EXHAUSTIVE 
SEARCH (NON-INDEXED 
& SUMMARIES) 

* * * NO SYSTEM ACCEPTABLE AT 1M RECORDS * * * 



Figure 7-5. DBMS Technology-First Level Performance Testing 

Results (FY 81) . 



Figure 7-6. LIMS Test Data Base-Load Summary. 
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INGRFS 

SEED VC0.03 
iwnpy orr-nun 

KEY OVERHEAD 
LOAD 

22- 57 

30. ?% 

9% - 161 



UPDATE 

52. 9* 

HI 

327 

63% 

??S% 

DELETE 

NC 

131 

20% 

??% 

30% 

DUPLICATION 
OF KEY VALUE 

LOAD 

NC 

NC 

2X:9Z 
5X : 21 
10X:.RI 

NC 

2X : 20% 

5X: 3% 

10X: 19% 
IMPROVFMFWT 

UPDATE 

NC 

NC 

NC 

R%-1 6% 

fj| 


NC 

tie 

NC 

n 

NC 


X DEGRAD -[ CONTROL TIME- TEST TIMf [ 
CONTROL TIME 
NC - NO CORRELATION 


Figure 7-7 . DBMS Technology-Second Level Performance Testing 
Results (FY82-FY83) (% Degradation Except Where 

Noted) . 


TEST 


rLnrunnr u .. 

# OF KEYED 
(9-+3-U) 

FIELDS 

— V/ 

SEED 

(VERSION B . 1 1 ) 



load _ 

3 KEYS 20X IMPROVEMENT 
1_KEY 58X IMPROVEMENT 

3 KEYS 28X IMPROVEMENT 
1 KFY 100X IHPROVFMFNT 

KEY LENGTH 
(BYTES! t\. 

8, 12) 


(VERSION CO. 03) 

INDEX RECORD 


load _ 

NC 

6X - 71 3f. 


QUERY „ 

5., 31 with 19 BYTFS 

NC Nr 

COMPLEXITY 
OF DB DESIGN 


(VERSION C0.02) 



LOAD _ 

6i£Z 

IR.9% 





HHMHRV9HI 


X DEGRADATION - 

CONTROL TIME - TEST TIME 



nnrnrot time 

NC - NO CORRELATION 


Figure 7-8. DBMS Technology-Second Level Performance Testing 

Results (FY82-FY83) (% Degradation Except 

Where Noted) 
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FIELD SIZE 
(BYTES: 10,20,31) 


if OF FIELDS 
(1X,2X,3X,7X) 


FIELD TYPE 
(INT*2 vs CHAR 2) 


DEGRADATION WITH INT*2 


*BX - 6*7X 


LGX - 8*6X 


CONTROL TIME - TEST TIME 


X DEGRAD J CONI KOL II 
NC - NO CORRELATION 


DBMS Technology-Second Level Performance Testing 
Results (FY82-FY83) (% Degradation) . 


ORACLE V2 


ORACLE V3 


INGRES 


SEED VB-11 


NON-DBHS CONTENTION 

LOAD AND REPEAT APP- NIX 

FORTRAN PROS* 5X TO 11X NOX TO NNX COPY 19X N7X TO 51X 


QUERY* £ 
COMPILE 


5 QUERIES* 

£ COMPILE N*1 


DBMS QUERY 
CONTENTION* 

# OF USERS 


SIMULT. SIHULT • 3 SEC* SIMULT- 3 SEC. SIMULT- 3 SEC* 

WAIT WAIT WAIT 


VARIATION 
IN LOAD 


CREATED: 
1X-8X 
RE- 1 N IT : 
15X 


3X - NX 


NC - NO CORRELATION 


•DEGRAD* 

FACTOR 


CONTROL TINE 


X DEGRAD 


CONTROL TIME - TEST TIME 


Figure 7-10. DBMS Technology-Second Level Performance Testing 

Results (FY82-FY83) (% Degradation) . 
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ORACLE V3 


INGRES 


SEED 


BUFFERING ; 

BUFFER # LOAD QUERY 


PAGE 
FAULTS 
IN LOAD 


50 

~ 

- 

- 

100 

25T* 

NC 

DEC 

200 

3NT* 

NC 

INC 


IDEAL BUFFER SIZE: 100 
^IMPROVEMENT 


SPACE DEF. ; 4. NT IMPROVEMENT 
WHEN INITIAL SPACE IS LARGE • 
CLUSTERING ; improper usage 

DECREASES PERFORMANCE BY 
FACTOR OF 3 


VARYING PRIMARY 8 
SECONDARY KEYS : 

For 13k db, secondary 

KEYS INSIGNIFICANT 
BECAUSE QUERY OPTIMI- 
ZATION BASED ON TABLE 
STATISTICS 

.lOURNAI 1NG ; 
lfi.51 DEGRADATION 
IN LOAD 


HA SHI NG A L GO R I THM : 

NO IMPACT BETWEEN USE 
OF CHARACTER ALGORITH- 
VS • INTEGER ALGORITH- 

JOURNALING : 

ROLL BACKWARDS : 

60T DEGRAD- 
TRANSCT • AFTER 
RECORD OR BURST: 

OT TO IT DEGRAD- 
BUFFERING : size of 

BUFFER IS SIZE OF 
LARGEST PAGE, NOT 
DIFFERENCE 


Figure 7-11. Variation of DBMS System Parameters. 


HEADER 


PRIMARYJEY 1 " " 


mining 

■JIH 

5DF 



il 1 

NUMBER, 
NOT NULL 

NUMBER, 
NOT NULL 


NUMBER, 
NOT NULL 

CHAR (31) 

CHAR (6N), 
NOT NULL 


'KEYED FIELD 
1 ROW » 11N BYTES 


Figure 7-12. PMS Oracle Data Base - Standard Design. 
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HEADER 










INT*2 

INT*2 

INT*4 

1NT*2 

CHAR (31) 

CHAR (64) 


•SECONDARY KEY 

THE COMBINATION OF MID_SID, SSC, SDF, AND TIME FORMED THE PRIMARY KEY- 
1 ROW - 107 BYTES 


Figure 7-13. PMS Ingres Data Base - Standard Design. 


: R1_H IDS I D : \ R2JJIME : !’ r5ZsDF 

r -ip j - r 

.....Li. 

: R5_MESSAGE 1 


1 LOGICAL RECORD - 116 BYTES 


1EC0RD NAME 

FIELD NAME 

TYPE 

R1_M I DS I D 

MIDSID 

I MT*2 

R2_T 1 ME 

TIME 

INT*4 

R3_SDF 

SDF 

INT‘2 

R4_PKEY 

PKEY 

CHAR*9 


MIDSID 

I NT*2 


TIME 

INT*4 


SDF 

INT*2 


HEADER 

CHAR*6t 


UIC 

INT*4 

R5_HESSAGE 

MESSAGE 

CHAR-31 


Figure 7-14. PMS Seed Data Base - Standard Design. 
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MAJOR ADVANTAGES 


MAJOR DRAWBACKS 


DBMS 

PACKAGE 

ORACLE 


EASY TO USE 

EASY TO CHANGE DB DESIGN 

GOOD FOR : - DYNAMIC SCIENTIFIC 
RESEARCH ENVIRONMENT 

- CASUAL USERS 


HIGH RESOURCE UTILIZATION 
PRODUCT NOT FULLY DEVELOPED 


CONCLUDE! 


OPERATIONAL ENVIRONMENT 
NEEDS IMPROVEMENT 


INGRES 


EASY TO USE 

EASY TO CHANGE DB DESIGN 

GOOD QUERY OPTIMIZATION 

SECURITY AND INTEGRITY 

GOOD FOR: - DYNAMIC, UNPREDICTABLE, 
SMALL TO MEDUM SIZE DB 
ENVIRONMENT 

- CASUAL USERS 


MAX OF 1 DISK PER DB APPLICATION 
INEFFICIENT LOAD RATES WITH KEYS 
QUERY LANG. LACKS CAPABILITIES 
NULL VALUES NOT EXPRESSED 


NOT GOOD FOR: 


LARGE DATA BASE 
APPLICATIONS 


SEED 


LOWER RESOURCE UTILIZATION 

MORE MATURE PRODUCT 

GOOD FOR: - OPERATIONAL ENVIRONMENT 
(RELIABLE) 

- STATIC DATA BASES 

- EFFICIENT DISK SPACE USE 


CREATING AND UPDATING IS COMPLEX 

CHANGING DB DESIGN IS A BURDEN 

RISKY FOR: - DYNAMIC, 

UNPREDICTABLE DATA BASES 

- CASUAL USERS TO CREATE 
AND MODIFY DATA BASES 


RIM WAS NOT CONSIDERED SERIOUSLY BECAUSE IT IS NOT AS COMPLETE OR THOROUGHLY IMPLEMENTED 
(E-G., SINGLE USER, NO REPORT WRITER, LIMITED USER VIEW CAPABILITY) 

Figure 7-15. Conclusions of DBMS Packages. 


0 PERFORMANCE TESTING SHOWS THAT VENDOR PACKAGES CAN MANAGE 
130 MEGABYTES OF DATA AT ACCEPTABLE LOAD AND QUERY RATES. 

0 PERFORMANCE TESTS VARYING DB DESIGNS AND VARIOUS DBMS PARAMETERS 
ARE VALUABLE TO APPLICATONS FOR CHOOSING DBMS PACKAGES AND 
CRITICAL TO DESIGNING EFFECTIVE DATA BASES. 

0 AN APPLICATION'S PRODUCTIVITY INCREASES WITH THE USE OF A DBMS 
BECAUSE OF ENHANCED CAPABILITIES: 

- SCREEN FORMATTER 

- REPORT WRITER 

- DATA DICTIONARY 


Figure 7-16. Conclusion. 
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0 FURTHER PERFORMANCE TESTS NEED TO BE MADE WITH NEW RELEASES 
(E.G., ORACLE V3) 

0 DATA BASE MACHINES SHOULD BE INVESTIGATED TO IMPROVE 

PERFORMANCE, ESPECIALLY TO SUPPORT MANAGEMENT OF VERY LARGE 
ON-LINE DATA SETS. 


Figure 7-17. Future. 


DOCUMENTATION: 

0 

0 

0 


TM 82176, ERB-6 DATA INVENTORY . JUNE 1981, R. SYLTO 
TM 83942, AUGUST 1981, E. MARTIN, R. SYLTO, ET AL 



p ^ f f |AN j \G^^y p ? y s yEM [^ameterizep performance 


MBHMKi UIII3 l*.l Jiii w.t I HL 


0 SUPPLEMENTAL PERFORMANCE TESTING . IN FIRST DRAFT 
MAJOR PRESENTATIONS: 

0 DBMS PANEL: THIRD WORKSHOP - DECEMBER 1980 
0 ISG OF OAST DSTP - OCTOBER 1982 
0 SEED USERS' GROUP MEETING - MAY 1982 
0 RE6I0NAL ORACLE USERS' GROUP MEETING - JUNE 1983 
CONSULTING WITHIN NASA: 

0 GSFC DYNAMICS EXPLORER GROUND SYSTEM 
0 GSFC SPACE TELESCOPE GROUND SYSTEM 
0 JPL OCEANS PILOT SYSTEM 
0 MSFC DBMS 

0 OAST ADMINISTRATIVE DATA BASES 


Figure 7-18. Publications of Results and Activities. 


84 



8. AUTOMATED ADMINISTRATIVE DATA BASES 

Michele D. Marrie (Presenter) Susan A. Reising (Presenter) 
Joyce R. Jarrett John E. Hodge 

Applications Resource Management Office 
Code 901, Goddard Space Flight Center, 

Greenbelt, MD 

BACKGROUND 


Over the past two years, members of the Applications Directorate Resources 
Management Office have developed a number of administrative automated 
systems in order to respond to the evei — increasing Internal Management, 
Center, and Headquarters requirements for information. The various 
requirements were calling for the same time of information from many levels 
at the Center on a fairly routine basis. 

It became apparent that a significant improvement in productivity and the 
ability to respond more effectively could be achieved using automated 
techniques . 


APPROACH 


A detailed review of the previous method of providing this information was 
conducted and the problems associated with each were highlighted. An 
analysis was made, and the areas that warranted automation were: 

o Civil Service Manpower 

o Research Technology Objectives and Plan (RTOPs) 
o Full Time Equivalency (FTE) 
o Training 
o Work Requests 
o Reimbursable Agreements 
o Physical Space 
o Travel 

o Furniture Budgeting 
o Copier Inventory 


EQUIPMENT 


HARDWARE 


Existing hardware, the IBM 4341, was used in all cases. Existing CRTs, 
printers and modems of various types were used. 
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SOFTWARE 


Existing software, the RAMIS Data Base Management System, was used. The 
IBM Time Sharing Option (TSO) utility was also used to allow more efficient 
use of RAMIS. Flexibility for expansion to accommodate other GSFC and 
Headquarters users was considered throughout the development phase of our 
resources systems. Training was provided to internal personnel who would 
use the system. 

MODULES SELECTED FOR PRESENTATION AT CONFERENCE 


MANPOWER 


An annual exercise which involves submission of plans to Center and 
Headquarters management prompted the development of this automated 
activity. The previous manual method was found to be very time consuming, 
required a large volume of paperwork, and involved a large quantity of 
manual calculations which impacted the accuracy level. 

By using the RAMIS automated system our steps in the manpower exercise were 
reduced from 16 to 10. The benefits we have derived thus far are listed 
below: 


o Elimination of loadsheets and manually prepared summaries. 

o Rejects available for review and correction faster and without 
loadsheets — many were handled via telephone. 

o By-name data is available for hiring/staffing plans and analysis 
throughout the year. 

o Consolidation of paperwork as information is transferred via 
printouts. 

o Summaries available from these data bases provide various levels of 
detail which are used to assist in variance analysis throughout the 
year. 

o SOW data can be used as a guide during next exercise. 

o There are fewer manual calculations: required accuracy rate improves 
because significantly fewer rejects received. 
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RTOPs 


A labor-intensive annual exercise which involves submission of proposed 
dollar and manpower amounts for each task and RTOP to Center and 
Headquarters management prompted automation of this activity. The previous 
manual method was time consuming, required a large volume of paperwork, and 
was considered to have a debatable level of accuracy due to the large 
amount of manual calculations necessary. 

Benefits we have realized from using the automated RAMIS system are 
highlighted below. 

o Reduction of paperwork, i.e., logs, handwritten summaries 

o Active data base to refer to throughout the year 

o Increased level of accuracy due to fewer manual calculations 

o Capability for the Financial Management Division (FMD) to retrieve 
data directly from our data base eliminating need for paper 
submission by due date 

* PILOT * 

o Automatic data transfer of Headquarters guidelines to GSFC ! s 
data base 

o Automatic data transfer from GSFC's data base to Headquarters' 

data base. 

FULL TIME EQUIVALENCY (FTE) 


There is a quarterly Center exercise and a monthly Directorate exercise to 
provide full time equivalency (FTE) information. 

We found the manual method previously used to be very time consuming due to 
manual calculations and preparation of reports, and we had a debatable 
level of accuracy because numerous calculations had to be performed. 

The present method was developed using a RAMIS database allowing us to 
input the data and print out our report for submission to the Personnel 
Division. 
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Benefits we have received from the automated system are as follows: 

o Time savings and increased accuracy due to elimination of manual 
calculations, and use of Center data base housing actual data 

o Ability to obtain recovery rate automatically 

o Elimination of typed report 


PHYSICAL SPACE 

There are three requirements for physical space information: 
o Annual Zero-base Space Exercise 
O Annual Building Space Utilization Exercise 
O Space Management needs 

The previous method used to compile the data was to conduct numerous 
physical walk-throughs and submit manual inputs. 

The problems we found were that the data was insufficient for internal 
space needs and the walk-throughs were extremely time-consuming. 

Therefore a new method was developed using a RAMIS data base. 

The benefits experienced were that: 

o Level of effort was reduced for Center exercises. 

o All formats for the Center exercises were prepared via computer. 

o The system was able to facilitate other exercises such as: 

- Internal division/directorate space management needs 

- Personnel on-board (grants, coops, visiting scientists, etc.) 

- On-site contractor exercises, etc. 


SUMMARY 


As you have noted from the four modules selected for presentation, benefits 
of automation include reduced duplication, increased communication, time 
savings, etc., and the potential for a much greater savings by sharing and 
integrating with those who have the same requirements. 

Since other field centers often respond to Headquarters requirements as 
Goddard does, it is hoped that our systems can be shared to extend these 
benefits to other parts of the Agency. Additionally, we look forward to 
learning and utilizing systems developed by other agencies in order to 
continually improve productivity and efficiency through automation. 
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9 . METHOD FOR ACCESSING 
DISTRIBUTED HETEROGENEOUS 
DATABASES 

Barry E. Jacobs 

DepartMent of Conputer Science 
University of Maryland 
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PROBLEM: Given a set of heterogeneous distributed 
databases, how can a user uniforwly I 
access all of the data? 1 



potential user 


relational 

database 



Figure 9-1 


o Illustrative Scenario 
o The Global Data Manager 
o The Conponents of the Global Data Manager 
o Research in Progress 
o Siomary 


Figure 9-2. Outline of Talk. 



travel 

idft 

naMe 

date 

state 

loc 

1111 

jones 

3.12 

calif 

jpl 

2222 

SMith 

4.23 

texas 

jsc 

3333 

green 

3.28 

calif 

arc 







funding 

id# 

naMe 

date 

fund 

purp« 

1111 

jones 

3.12 

sk46 

— 

2222 

SMith 

4.23 

f j55 

— 

3333 

green 

3.28 

rk44 

— 







o This is an ORACLE relational database which is 
physically located at Goddard Space Flight Center. 

o The data is stored internally in ASCII. 


Figure 9-3. A Relational Database. 


trip 

(date, fund, purp) 

itinerary 
(state, locat) 



state locat 


o This is an INS hierarchical database which 
is physiclly located at Jet Propulsion Lab. 

o This data is stored internally in EBCDIC. 


Figure 9-4. A Hierarchical Database. 
































is physicaly located at NASA headquarters. 


o The data is stored internally in ASCII. 


Figure 9-5. Network Database. 



HEADQUARTERS 


employee 



posit 



GODDARD 

(ASCII) 


JFL HEADQUARTERS 

(EBCDIC) (ASCII) 


Figure 9-6 
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Local 

DBMS 



Local 

DBMS 


DISTRIBUTED HETEROGENEOUS DATABASES: THE GLOBAL DATA MANAGER 


Figure 9-7. Distributed Heterogeneous Databases: The Global 

Data Manager. 


o Is a unifom "front-end" that can be placed 
on top of each of the participating data Models. 


o 



It should capture enough of the features of the 
underlying Models but not generate too large a 
loss in perf orttance . 

It should not only be used as a front-end for 
the databases, but also as a front-end for the 
data dictionary and data directory. 


Figure 9-8. The Global Model. 
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In database logic, relational databases appear 
the sane way to the user. 


Figure 9-9. The Relational Database at GSFC. 
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In database logic, databases appear as 
"tables within tables.” 


Figure 9-10. The Hierarchical Database at JPL. 
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In data base logic the user sees the data base as 
"tables within tables." 


Figure 9-11. The Network Database at NASA Headquarters. 


external view 


external -to-conceptual Rapping 


conceptual view 


o External views can provide classes of users with 
their own "view” of a data base. 

o External views can facilitate user queries. 


Figure 9-12. External View of a Conceptual View. 
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o The conceptual view is wade up of the data bases frow 
Goddard and JPL. 

o All values are in ASCII to the user. 


Figure 9-13. An Example of an External View. 


The user's global view is the database that 
the user can iwagine is actually located on 
the coHputer on which he/she resides. 

The global view is often wade up of the union 
of different views. 

If data types differ (say, EBCDIC to ASCII) the 
user can pretend that all types are the sane, 
say ASCII, and let the systew deal with the 
conversion. 
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Figure 9-14. The User's Global View. 
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o The global DHLs fall into two classes- 
non-procedural DHLs 
and procedural DHLs. 


Figure 9-15. Global Data Manipulation Languages. 


select cent-enployee.idi. cent-eMployee.nawe, 
cent-ewployee. title 
froM cent-ewployee, travel 
where 

state=calif 

and cent-eMployee.idt=travel.id# ; 



Figure 9-16. Generalized SQL DML. 
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travel 

id# 

nane 

date 

state 

loc 

id#:! 

nai«e:l 


calif 



cent 


center 

ewployee 

id# 

id#:! 

na*e 

naHe:l 

title 

title:! 

center 


result 

id«:l 

naite:! 

title:! 


Figure 9-17. Generalized QBE DML. 


get v <id#:l, nane:!, title:!) : 

(E)date:!. . . (E)center:i 
travel (id#:!, na*e:l, date:!. cal if . loc:i) 

& cent-eMployee(center:l,eHployee:i, id#*. 1, naMe'.i, title: 1, center: 1); 



Figure 9-18. Generalized Calculus (GCALC) DML. 
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Figure 9-19. Global Dictionary /Directory . 



Figure 9-20. External-to-Conceptu&l Translation. 
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Figure 9-21. Logical Optimization. 
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Figure 9-22. Query Decomposition. 
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Figure 9-24. Assembly. 
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temp(3) 


result 



Figure 9-25. Loading* 




o Many queries are Being 
handled simultaneously. 

o Both process commands 
and data are regarded as 
"messages* that are Being 
transferred Between nodes. 

o Queries which appear to 
yield no answer are killed. 

o Communication Breakdown 
has to Be suitaBly handled. 


Figure 9-26. Process Control and Communication. 
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select:state=calif; select state=calif; semi Join :idft=idi; 

(at gsfc) (at jpl) (at NASA Head?) 



Figure 9-27. Local DML Processes. 


The development of the Global Data Manager is being coordinated 
by the Information Management Branch at GSFC. Participating 
universities include: 

o Ihe University of Maryland 
o Ihe Catholic University of America 
o Towson State University 
o Stevens Institute of Technology 
o The City University of Neu Vork 

Figure 9-28. Research in Progress. 
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o DAVID (Distributed Access View Integrated Database) 
System is based on the recently developed frawework called 
database logic. 

o Its purpose is to enable users to easily access 
databases which are heterogeneous and physically distributed. 

o Our Hodus-operandi is siwple. He generalize the 
relational approach to the heterogeneous approach using 
database logic as our vehicle. 

o Further details can be found in 

"APPLIED DATABASE LOGIC II: HETEROGENEOUS DISTRIBUTED 
QUERY PROCESSING" PRENTICE-HALL (EXPECTED JAN. 1984). 

Figure 9-29. Summary. 
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10. NASA SCIENTIFIC AND TECHNICAL INFORMATION SYSTEM (STI) AND 
NEW DIRECTORY OF NUMERICAL DATA BASES 

John Wilson 
Headquarters Code NIT 

Those of us who have responsibility for it, in all modesty, think that 
NASA's STI System is the biggest, most agile, best managed, and most useful 
collection of aerospace information in the world. The total system includes 
the facility out at the Baltimore-Washington Airport; the parallel facility 
run for us by the AIAA in New York City; the STI Branch in Washington, the 
minisy8tems constructed at each of the NASA Centers and contractor sites; 
and arrangements with the European Space Agency for inputting reports of 
member nations and access to the data base. The STI Branch in Headquarters 
has existed for more than 20 years. 

Looking at the NASA-wide technical information system, we immediately 
spot the inconvenient fact that each Center's STI operations are organized 
differently. In all NASA and JPL about 200 civil-service people and 350 
support-service contractors work in technical information. They are supported 
altogether by funds in excess of $30 million annually. 

At the heart of the system is the collection, a huge body of scientific and 
technical information collected from worldwide sources. It's big- -currently 
containing over 2.2 million individual items. It's also dynamic, growing at the 
rate of 140,000 items per year. We have a number of quality-control and filtering 
methods to keep this massive data base from turning into a squirrel's nest. 
Principal elements in this data base are reports, journal papers, presentations, 
and books. If it's been put on paper or film, and if it's on NASA's mission 
and given any reasonable degree of release, we ought to have it. 
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What we do with this tremendous collection is what the system is all about. 
It's fairly easy to microfilm the documents and distribute them promptly to 
Centers and contractors. There are at least a dozen different ways we assemble 
and parcel out specific slices for individuals and groups of users. We issue 
two abstract journals, on alternating weeks, that announce and abstract new 
material, one for reports, and one for journal papers and books. Both of these 
journals, Scientific and Technical Aerospace Reports (STAR) and International 
Aerospace Abstracts (IAA), carry indexes that allow a user to search by subject, 
author, originating institution, contract number, or report number. They are 
produced rapidly and permit about as sophisticated search and retrieval as can 
be managed by ink on paper! 

But th$se journals, even with a set of cumulated indexes, are really neither 
fast enough or comprehensive enough to suit many NASA needs. Typically, when a 
searcher wants to know what's been done in a specific area, he wants to know a 
little more than simply what's been done recently. There is a great deal of 
serendipity in a really satisfactory search: it's a kind of random walk into 
unknown terrain. For this, nothing to date has proved better than our NASA/RECON, 
an online bibliographic search system of almost eerie responsiveness. NASA 
pioneered with this system in the 1960s and 1970s; in the intervening period 
REGON has been steadily growing in responsiveness, speed, and precision. RECON 
currently responds to over 12,000 separate commands a day, most of them from over 
250 terminals and password holders. 

One interesting part of RECON is NALNET, containing a listing of journals 
and books held by each NASA Center library. This means that our libraries need 
not maintain costly duplicate collections for local use but can arrange for 
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rapid interlibrary loans of titles on demand. 

There are countless by-product advantages of our methods of accessing the 
collection. To produce the big abstract journals, for example, we need standard- 
ization citations, abstracts, and indexing. To re-sort this material into 
specialized products for special audiences, all it takes is some relatively 
uncomplicated software. It permits us to generate, at low cost and without 
delay, continuing bibliographies in aeronautical engineering, aerospace biology 
and medicine, earth resources and energy, large space structures technology, and 
management. Note that this material, sorted from the main input stream and 
presented for particular readerships, is acquired at virtually zero incremental 
cost and effort. 

We also assist Headquarters offices in devising or producing their own 
special data bases and publications including the RTOP (on-going NASA R&D 
projects) annual, the yearly "green book" of university contracts and grants, 
the indexes of NASA management issuances, and a new online index for NASA 
safety reports. The Patent Bibliography is issued for the Patent Counsel. 

DIRECTORY OF NUMERICAL DATABASES (DND) 

A new service, the Directory of Numerical Databases (DND) is now accessible 
to engineers and scientists through online searching of the NASA/RECON system. 

DND is a referral listing of scientific and technical data bases which can be 
shared among NASA staff and contractors who have an interest in a specific 
technical data set. The DND provides a brief description of each listed data 
base and gives the name and phone number of a contact person from whom access 
details may be obtained. 


107 



Initially, descriptions of more than 140 data bases are provided, covering 
a broad range of technical fields in which NASA has an interest. The data bases 
listed in the DND were identified and described through the cooperation of all 
of the NASA Centers. Additional listings are being received, and the file is 
expected to grow in usefulness to the technical community as it becomes more 
comprehensive. This project is a part of an effort in NASA to improve the 
management of numerical data. Making information about that data more readily 
accessible will help assure that the maximum benefit is obtained from the 
dollars invested. 

PROPOSED NASA-WIDE INTEGRATED LIBRARY SYSTEM 

A NASA-wide Integrated Library System (ILS) is being developed for the 
Center libraries. The system will be composed of several subsystems: 
o Online Catalog 
o Acquisition Subsystem 
o Circulation Control Subsystem 
o Information Retrieval Subsystem 
o Management Information Subsystem 
O Authority File Subsystem 

Each of the above subsystems will interact with online files which are 
identified as : 

o Bibliographic files 

- Documents 

- Books 

- Journals 
o Patron files 
o Vendor files 
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The proposed system will be modular in terms of both hardware and software. 
Other proposed requirements include but are not limited to expandable memory and 
direct memory address. The system must be capable of performing I/O through a 
variety of remote terminals consisting of high-speed CRT terminals and OCR or 
zebra label scanning devices. Initial storage requirements for the several 
files will consist of an estimated one hundred million characters of online storage 
with input at an estimated daily rate of 20,000 characters/day. Ihe applications 
will also require the ability to off-load data for eventual archival use. 


2.1 M RECORDS 



Figure 10-1. Nasa Facility Data Base. 
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8104177(1* ISSUE 19 
UNCLASSIFIED DOCUMENT 
IITTL 5 imenU»4-*<j.tudy on 

( 1 . G(y and 0 G . micron lasers 


PAGE 3417 CATEGORY 
DCAF AG 1 0606 
wavelength scaling In 


75 81/03/00 11 PAGES 

laser fusion by using 0.53, 

E/1MADA, Y 


AUTH: VUiSHIHlIRTn-'ll.; B/A2ECHI, H.: C/YAI1ADA, K.; D/1AMURA, A., 

; F/NATSUOKA, F.J G/HAUADA, N.; H/SUZUKI, Y.1 I/NAKA1, S.J 
J/YAMAHAKA, C. • PAA: .(/(Osaka University, Osaka, Japan) 

Osaka University, Technology Reports, vol. 31, Mar. 1931, p. 97-107. 

MAJS: /*ABLATI0N/#ENERGY TRANSFER/* INFRARED ADSORPTION/* INFRARED LASERSALASER 
FUSIONALASER PLASMA INTERACTIONS 

HINS: / CARBON DIOXIDE LASERS/ ELECTRON ENERGY/ GLASS LASERS/ LASER TARGETS/ 
PLASMA ACCELERATION/ PLASMA TEMPERATURE/ X RAY SPECTROSCOPY 

ADA: (Author) 

ABS; Experimental studies of the wavelength dependence of several laser-plasma 
coupling processes were performed. These were! (1) laser light absorption 
(2) energy transport, and (3) ablation and target acceleration behavior. 
At a laser intensity of around 10 to the 14th W/sq cm, the ablation 
process wav'TJoTrri na led by heat transport due to cold electrons for G.53 
jw«on andM , OG/mlcron lasers and was dominated by hot electrons for the 
0 RjSj mlcj oaHtr^er . 


Figure 10-2. Publication Typical Entry. 


83A12347# ISSUE 2 PAGE 1 VB CATEGORY 35 82/00/00 9 PAGES 

UNCLASSIFIED DOCUMENT 

UTTL: Optical sensor for measurement of position and deformations of models in 
wind tunnel 

AUTH: A/SURGET, J.; B/PHILBERT , M . : C/DUNET, G. PAA: C/C0NERA, 

Chat i 1 lon-sous-Bagneux , Hau ts-de-Se i ne , France) 

La Recherche Aerospatiale (English Edition), no. 3, 1982. p. 43-51. 

MAJS'. AFIBER OPTICS/ ^OPTICAL MEASURING INSTRUMENTS/* TRAILING EDGESAHIND TUNNEL 
MODELS/»HIND TUNNEL TESTS 

MINS: / CALIBRATING/ FLOW VELOCITY/ SENSORS/ WINGS 

ABA: R.K.R. 

ABS: The design of an optical position sensor produced to allow the 

localization of the trailing edge of a wing placed in a wind tunnel is 
presented. The instrument consists of the sensor itself, an electronic, 
cabinet, and a control box. In calibrating the instrument, it is noted 
that dispersion of the location of the tip of the optical fiber never 
exceeded plus or minus 0.01 mm, and no apparent drift was detected. 
Validation was performed by compar i ng pos ition indications obtained using 
in optical sensor and a mechanical feeler. Tests are performed at three 
tlow velocities, and it is found that the device functions satisfactorily. 
The principal advantages of such a device include sensitivity, absence of 
drift, and ease of operation. 


Figure 10-3. Journal Article Entry. 



83N 12345V ISSUE 3 PAGE 363 CATEGORY 33 RPT#: PB82- 178989 
NBSIR-81 -1.656 81 /1 2/GO 181 PAGES UNCLASSIFIED DOCUMEN1 

UTTL: MBS 30/60 Megahertz Noise Measurement System Operation and Service Manual 
flUTH: A/COUNAS, G.: B/BREMER, T. 

CORP: National Bureau of Standards, Washington, D.C. AVAIL. NTIS SAP: HC 
A09/MF AG1 

MAJS: /’ELECTROMAGNETIC NOISE/*MANUALS/*NOISE MEASUREMENT /*NUMF.RICAL CONTROL/* 
RADIOMETERS 

MINS : / CALCULATORS/ COAXIAL CABLES/ MAINTENANCE 
ABA: Author (GRA) 

ABS: The general theory of operation, operating procedures, and maintenance 

procedures for an automated noise measurement system using a commerc ia 1 ly 
available desktop calculator as the controller are described. Calibration 
of coaxial noise sources at 30 and SC MHz using a total power radiometer 
designed to operate under computer control is described. Use of the IEEE 
488 instrument bus and structured software techniques allows substitution 
of commercially available components with a minimum of hardware and 
software modification. 

Figure 10-4. Report Entry. 
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83X10001 
1370642 

National Aeronautics and Space Administration. Langley Research Center, 

n «3 tfl p ton , v a • 

Advanced Automation. Inc., Urbana, 111. 

A feasibility study in, and planning for, application of advanced computer 

Hi monitoring and analysis techniques 

UNCLASSIFIED NOVEMBER 5, 1982 / MAY 4, 1983 

A/SAMMS. X. H. A/246B 

REPORTS EXPECTED 

/ *AIRBORNE/SPACEB0RNE COMPUTERS/* ART IF ICIAL IN rELLIGEITCEACOMMERCI AL 
f ) I cTMnri^n 0MPUTER PR0GRAMHING/*C0HPUTER. TECHNIQUES/* IN-FLIGHT MONITORING 
/*SIMUL ATION/*SYSTEM FAILURES/* WARNING SYSTEMS 


Figure 10-5. Contract Entry. 
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S3W7G573 31 0-A0-4S 

UTTL: Mission Operations Technology 

SANFORD, R. G. 301-344-6138 

National Aeronautics and Space Administration. Goddard Space Flight 
Center, Greenbelt, Md. 

The mission operations technology RTOP is a subsystem level RTOP, the 
objective of which is to transfer state-of-the-art hardware, software, and 
automation technology to the mission operations environment to improve 
operations efficiency and reliability and reduce costs. This RTOP is 
divided into two tasks; control center automation and distributed control 
research. The control center automation task seeks to develop a highly 
automated operations control center capable of supporting multiple 
simultaneous missions by the study and specification of the levels of 
automation for systems resource allocations, connection, test, and status 
reporting. The distribution control research task will provide the 
technology required for a workable distributed mission control environment 
by the deve lopmen t and implementation of a distributed command management 
software systems. 

HAJS: /^AUTOMATIC CONTROL/* COMM AND AMD CONTROL/COMPUTER NETW0RKS/*C0MPUTER 

PROGRAMS/-* COMPUTERS/* GROUND DASED C0NTR0L/->GR0UND STATIONS/*MANAGEMENT /* 
ON-LINE SYSTEMS/*0FERA1 IONS/* SUPPORT SYSTEMS 

Figure 10-6. RTOP Entry. 



Figure 10-7. STL Facility Systems. 
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Figure 10-8 
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Figure 10-9. Major Software Systems Interfaces. 
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Figure 10-10. NASA/RECON System. 


83F101C8 

Significant Wave Height (SEASAT A AJtimete) (SWH/SA) 

DATABASE' TYPE: NUMERIC 

GENERAL DESCRIPTION: Significant wave height was derived from an analysis of 

return waveforms of the leflected microwave pulse. The derived values are 
in meters. The SEASAT A Altimeter data were processed to provide 
geophysical and sensor files, lhe geophysical files contain significant 
wave heights, mean sea surface elevations, and wind speed. The sensor 
files contain primary measurements and include significant wave heights 
with derived engineering units which give the shape of the return pulses. 
DA1A QUALITY: Geoid agreement was shown with independent observations from 
buoys, underflying aircraft and from the Gulf of Alaska SEASAT Experiment 
(GOASEX). The attained accuracy is + or - 38 cm for significant wave 
height less than Sm and perhaps for significant wave height less than 8 m; 
and i or - 1 m for significant wave height less than 10 m. OUTPUT 
PRODUCTS: The SEASAT A Altimeter data set is available in two forms on 
9-track, 1800 and 1G00 bpi computer compatible tape. The Sensor Data 
Records (SDR), Level I, contain engineering data and the results of 
onboard processing: orbit information, time of observation; waveforms, 
nadir range, significant wave height, and ocean backscatter. The 
Geophysical Data Records (GDR), Level II, were obtained by processing the 
SDR. They contain measured nadir range, list of applied corrections, 


including tied corrections, sea surface elevation, position (iatitude and 
longitude), geoid information, significant wave height, and wind speed. 

DATA COLLECTION METHOD: SEASAT A Alitmeter 

KEYWORDS: / * BACKSCA TTERING/>ELEVAT1 ON/ < GEO IDS/* OCEAN SURFACE/ ^OCEANOGRAPHIC 

PARAMETERS/-* RADAR MEASUREMENT /-<RADAR RANGE/*RADIO ALTIMETERS/*SEA LEVEL/* 
SEASAT PROGRAM/*SEASA'( 1/*NINB VEL0CI1Y 

7IMESPAN: 780707 - 781010 

AREA COVERED: The SEASAT A Altimeter obtained data between + or - 72 deq on 

1400 orbits, with an orbit-track separation at the equator of 20 km to SO 
km. SPATIAL/ TEMPORAL RESOLUTION: Along the suborbital track, data were 
collected every millisecond from circular parches of sea surface 2.4 km to 
Id’ km in diameter. The footprints are 2.4 km to 12 km wide and 0.6 km to 6 
km longer in the orbit direction. Repeat observations were made where 
orbits crossed; selected orbits were repeated 9 times at 3-day intervals. 

NASA CENTER: National Aeronautics and Space Administration. Goddard Space 

Flight Center, Greenbelt, Md. 

CONTACT: Eugene R. Hoppe, N0AA/SDSD, World Weather Building, Washington, D.C. 

2C233 , 301 -763-31 1 1 

DATA SOURCE: National Aeronautics and Space Administration. Wallops Flight 

Center, Wallops Island, Va . 

PROGRAM: SEASAT A Satellite 

DOCUMENTATION: Information Management Branch, GSFC. 1982, NASA Climate Data 


Catalog. U.S. Department of Commerce, Satellite Data Services Division. ' 
Satellite Data Users Eullc-tin, Vols. 1.1, 1.2. 2.2. 0A0 Corporation, 1981. 
SDSD First Level Catalog System, Technical Report No. 0A0/SD- 81 /0007 . 
COMMENTS: lhe SASS, SMMR, and Virr instrument data sots from SEASAT and the 

GEOS 3 Altimeter data set provide related data. 

NASA/NON-NASA: NASA 


CAT. CODE: 43 SECURITY CLASS: 

DATE RECEIVED: 82020C 


UNCLASSIFIED 


Figure 10-11. Typical Entry, Directory of Numerical Data Bases. 
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• ONLINE CATALOG 

• AUTHORITY FILE CONTROL 


Figure 10-12. Conceptual Overview of the NASA-Wide Integrated Library System. 
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Figure 10-13. Model Participating Library Configurations. 
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Figure 10-13. Model Participating Library Configurations (Continued). 
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Figure 10-14 













11. SPECIFICATIONS FOR A FEDERAL INFORMATION PROCESSING 
STANDARD DATA DICTIONARY SYSTEM 


Alan Goldfine 

Institute for Computer Sciences and Technology 
National Bureau of Standards 


1. INTRODUCTION 


As the world's largest user of information processing 
technology, the Federal government is highly dependent on 
the use of this technology for carrying out government-wide 
programs and delivering essential services. Accordingly, 
data management software is a tool of rapidly increasing im- 
portance that merits special attention in its acquisition 
and use. The Institute for Computer Sciences and Technology 
(ICST) is addressing the need for standards and guidelines 
in this area in its Data Management Program. 

A key software component for the management of informa- 
tion resources is the Data Dictionary System (DDS) . A data 
dictionary system is a computer software system that pro- 
vides facilities for recording, storing, and processing in- 
formation about an organization's significant data and data 
processing resources. 

ICST is developing a Federal Information Processing 
Standard (FIPS) Data Dictionary System. The FIPS DDS will 
be a software specification that Federal agencies may use in 
the evaluation and selection of DDSs. These specifications 
will not require an agency to use a data dictionary or to 
use one in a prescribed manner. 

Federal agencies use DDSs to: 

® inventory their data resources 

o support the system development life cycle 

© inventory computer equipment and software 

« support data element and documentation standardiza- 
tion 

e provide a directory to locate data in centralized or 
distributed environments 

Given this usage, a FIPS for a Data Dictionary System will 
benefit agencies by: 
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® providing standard specifications that can be used 
in the selection, evaluation, and procurement of DDS 
software 

is aiding in the portability of both DDS software and 
DDS data 

© supporting portability of acquired skills, since 
agency personnel will not need to learn a new user 
language to use another DDS 


2. THE NATURE OF THE FIPS 

To supply the flexibility needed by all the widely 
differing applications and environments in the Federal 
Government, the FIPS will specify a "core" DDS together 

with a set of optional modules. The core will provide basic 
support for the prime areas of DDS use identified above and 
can be implemented on small as well as large computer sys- 
tems. Each additional module will contain more advanced 
features that will result in a more powerful and complex 
DDS. 

The FIPS DDS will specify : 

© a "stand-alone" DDS, independent of specific 

hardware and software 

© complete user interfaces to the DDS, including syn- 
tax and semantics for data description, input, out- 
put, and manipulation commands 

® "extensibility" — the facility that will allow an 
agency to customize the structure of the contents of 
the DDS to accommodate its user needs 


3. PROJECT FOCUS 

The objective of the ICST project is to develop specifi- 
cations that support Federal agency requirements , and that 
will be implemented by a wide spectrum of software suppliers 
(and thus be available "off-the-shelf"). To do this, the 
project is based on the following approach: 

® close and continuing interaction with Federal users 
to. determine which specific capabilities are re- 
quired by a sufficiently large segment of the 
Federal community 
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o detailed technological assessments and intensive 
consultation with hardware and software vendors, the 
research community, and Federal developers of in- 
house data dictionary systems, to determine 

whether it is technologically practical to 
develop a particular capability in the near 
future, i.e., the next three to five years 

if technologically feasible, whether it is 
economical for the software industry to pro- 
duce such a capability in a competitive mar- 
ket 

® contractor support from the Alpha-Omega Group, Inc. 
in the development of the specifications 

© solicitation of comments and suggestions from all 
affected communities throughout the developmental 
process by issuing periodic reports and conducting 
workshops 

» continuing interchange with the American National 
Standards Institute (ANSI) Technical Committee X3H4 
to ensure consistency with the planned national 
standard for a DDS, named the Information Resource 
Dictionary System (IRDS) 

® coordination with the Office of Management and Budg- 
et (OMB) to 

review the prototype Federal Information Lo- 
cator System (FILS) that OMB adopted in im- 
plementing the Paperwork Reduction Act of 
1980 (P.L. 96-511) 

ensure that the planned FIPS DDS is compati- 
ble with the FILS when it becomes fully 
operational 

® assistance to the Department of Defense Ada Joint 
Program Office by conducting an "Evaluation of the 
Applicability of the FIPS DDS to the Ada Environ- 
ment" 
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4. 


PROJECT STATUS 


The work plan for developing a FIPS DDS was divided 
into the following five phases: 

© state-of-the-art assessment of DDS technology 

© requirements definition 

@ development of preliminary core DDS functional 
specifications 

© development of complete core FIPS DDS specifications 

© specification of optional FIPS DDS module (s) to pro- 
vide additional capabilities 

During the first phase, ICST analyzed relevant litera- 
ture and existing commercial and Federally developed data 
dictionary systems. Features and capabilities in the current 
generation of DDSs were identified. A preliminary assess- 
ment identified projected technological trends and issues 
that warranted further investigation. ICST also sponsored 
the third Data Base Directions workshop, which focused on 
data dictionary systems. The following three products were 
published during the first phase: 

© Prospectus for Data Dictionary System Standard Cl]. 
The Prospectus discusses the use of data dic- 
tionaries and describes ICST's plans to develop a 
Federal Information Processing Standard for Data 
Dictionary Systems. ICST encouraged technical input 
on the appropriate content for a FIPS DDS. 

© Guideline for Planning and Using a .Data Dictionary 
System ~~m — This publication discusses the capa- 
bilities and uses of data dictionary systems. It 
also provides Federal agencies with basic guidance 
on DDS selection, planning for the use of a DDS, DDS 
implementation, and operational usage of a DDS. 

© Data Base Directions: Information Resource 

Management — Strategies and Tools [3j . This report 
constitutes the results of the October, 1980 Data 
Base Directions workshop that investigated how 
managers can evaluate, select, and effectively use 
information resource management tools, especially 
data dictionary systems. 
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In the second phase of the project, ICST interviewed 
Federal agencies to identify current and projected require- 
ments for data dictionary software. Interview results, as 
well as comments received on the Prospectus, were summarized 
in Federal Requirements for a Federal Information Processing 
Standard Data Dictionary System £4). This report was dis- 
tnbuted in the fall of 1981 to Federal agencies, to sup- 
pliers of data dictionary software, and to other individuals 
and organizations in the private sector working with data 
dictionaries. 

Using the results of the first two phases, ICST worked 
closely with the ANSI X3H4 Technical Committee and with na- 
tionally recognized experts on data dictionary systems to 
develop the Functional Specifications for a Federal Informa- 
tion Processing Standard Data Dictionary System Q5] . Three 
Federal agency and one DDS vendor workshops were held to re- 
view preliminary versions of the functional specifications, 
and the published document [5J contains modifications that 
the Federal representatives felt were needed to satisfy 
agency requirements. The document represents the results of 
the third phase of the work plan. 

Work on the fourth phase started in October, 1982. Two 
products, which will constitute the FIPS DDS, are scheduled 
for development during this phase. These products are the 
DDS User's Manual , containing the specification of the user 
interfaces, and the DDS Implementors' Manual , containing 
guidance to be observed by the person or organization pro- 
ducing the DDS software. A Federal agency workshop to dis- 
cuss the strategy for development of the DDS user's inter- 
face was held in February, 1983, and another, to review 
preliminary user interface specifications, is scheduled for 
June, 1983. A vendor workshop is planned for September, 
1983. Current plans are to publish the complete FIPS DDS in 
fiscal year 1985. An interim report is scheduled to be pub- 
lished in fiscal year 1984 to obtain comments on the planned 
final draft of the FIPS DDS. 


5. FUNCTIONAL SPECIFICATIONS FOR THE FIPS DDS 

The DDS has three major components: 

® the Dictionary — the data contained within the DDS 

© the Dictionary Schema — a description of the gener- 
ic structure of the dictionary 

® the Dictionary Processing System — the set of pro- 
grams that interact with the dictionary and 
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dictionary schema to provide the functionality of 
the DDS 

The functional specifications are based on an entity- 
relationship-attribute (E-R-A) structure. This paper uses 
the following definitions: 

Entity — any named concept, object, person, event, 

process, or quantity that is the subject of stored or 

collected data 

Relationship — a predetermined ordering between pairs 

of entities 

Attribute — a property or characteristic of an entity 

5.1 The Dictionary 

A DDS entity represents or names an object, person, 
etc., but it is not the actual data that exists in a file or 
data base. Thus, a DDS entity might be "social-security- 
number" or "payroll-record." It would not be the actual so- 
cial security number "123-45-6789" or the actual content of 
a payroll record. Similarly, an attribute represents a 
characteristic of an entity. An example of an attribute of 
"social-security-number" is its length, e.g., "9 charac- 
ters." An example of a relationship is "payroll-record con- 
tains social-security-number." 

5.2 The Dictionary Schema 

Attributes can be organized into sets called 
attribute - types , so that each member of a set represents a 
like characteristic. For example, "DATE CREATED" is a typi- 
cal attribute-type. 

Similarly, entities can be organized into entity-types . 
All instances of a specific entity-type have similar or 
identical characteristics or attribute-types. "Social- 
security-number" is an example of an "element" entity-type. 

In the same manner, relationships can be grouped into 
relationship - types . All relationships, which are instances 
of a relationship-type, have attributes from the collection 
of attribute-types associated with that relationship-type. 
"System-contains-progr am" and "record-contains-element" are 
examples of relationships. (The concept of "type" is gen- 
erally regarded as a collection of "instances.") 
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These "types" are the basic structures of the diction- 
ary schema. The schema also contains structures used for 
the validation of attributes in the dictionary and for the 
support of the DDS status and staging facilities. 

This entity-relationship-attribute construction used 
for the dictionary can be used to model the schema as well, 
thus providing an effective framework within which to con- 
struct, manipulate, and extend the schema. In other words, 
"entity-type," "relationship-type," and "attribute- type" can 
themselves be thought of as "entities" at a higher level of 
description. Thus, the DDS contains a "meta-schema," or 
schema describing the schema. ("Meta" is used in the sense 
of "data about data".) As an example of extensibility, a 
new entity-type to represent equipment can be created in the 
schema by adding the appropriately defined meta-entity 
"equipment." A meta-relationship between "user" and "equip- 
ment" could then define the relationship- type "user-uses- 
equipment," and a meta-relationship between "cost" and 
"equipment" would specify "cost" to be an attribute-type of 
"equipment." 

5.3 The System Standard Schema 

In order for the FIPS DDS to provide Federal agencies 
with the full benefits of inter- and intra-agency communica- 
tion, the specifications include a specific collection of 
entity-types, relationship-types, and attribute-types. This 
collection, called the "system standard schema," is expected 
to be delivered as part of every software package conforming 
to the Federal Information Processing Standard. An agency 
can then augment this collection by using the extensibility 
feature. 

Reflecting DDS usage in the Federal government, the 
system standard schema provides for eight data, process, and 
external entity-types: 


Data Entity-Types 

© ELEMENT, to describe instances of data belonging to 
an organization. Typical ELEMENTS are "social secu- 
rity number" and "agency name." 

® DOCUMENT, to describe instances of human readable 
data collections. Typical DOCUMENTS are "Form 1040" 
and "FIPS Guideline." 

« RECORD, to describe instances of logically associat- 
ed data. Typical RECORDS are "employee record" and 
"payroll record." 
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® FILE, to describe instances of an organization's 
data collections. Typical FILEs are "roster" and 
"accounts receivable." 

Process Entity-Types 

® SYSTEM, to describe instances of collections of 
processes and data. Typical SYSTEMS are "personnel 
system" and "airline reservation system." 

® PROGRAM, to describe instances of automated 
processes. Typical PROGRAMS are "roster update" and 
"COBOL compiler." 

© MODULE, to describe instances of automated processes 
that are either logical subdivisions of program en- 
tities or independent processes called by program 
entities. Typical MODULES are "sort records" and 
"main program." 

External Entity-Types 

® USER, to describe members belonging to an organiza- 
tion who use or are responsible for data in the data 
dictionary system. Typical USERs are "John Doe" and 
"personnel division." 

Additionally, DICTIONARY-USER (to identify individuals 
and access privileges) and ACCESS-CONTROLLER entity-types 
are specified for the Dictionary Administrator to use in the 
management of the DDS's security system. 

The relationship-types in the system standard schema 
include virtually all the connections between system stan- 
dard entity-types that might prove useful to most agencies 
most of the time. The majority of these relationship-types 
are themselves grouped into classes. The six main classes 
are: 

® CONTAINS, to describe instances of an entity being 
composed of other entities. A typical CONTAINS 
relationship-type is RECORD-CONTAINS-ELEMENT, which 
has as a possible instance the relationship 

"Payroll-record-contains-employee-name. " 

® PROCESSES, to describe associations between DATA and 
PROCESS entity-types. A typical PROCESSES 

relationship-type is SYSTEM-PROCESSES-FILE, which 
has as a possible instance the relationship 

"budge t-system-processes-cost-center-f ile. " 
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« RESPONSIBLE-FOR, to describe associations between 
entities representing organizational components and 
other entities to denote organizational responsibil- 
ity. A typical RESPONSIBLE-FOR relationship-type is 
USER- RESPONSIBLE-FOR- DOCUMENT, which has as a possi- 
ble instance the relationship "personnel-off ice- 
responsible- for-SF-171 . " 

® RUNS, to describe associations between USER and PRO- 
CESS entity-types, illustrating that a person or or- 
ganizational component is responsible for running a 
certain process. A typical RUNS relationship-type 
is USER-RUNS-PROGRAM, which has as a possible in- 
stance the relationship "John-Doe-runs-sys tern- 
backup. " 

© TO, which describes "flow" associations between PRO- 
CESS entity-types. A typical TO relationship- type 
is MODULE-TO-MODULE, which has as a possible in- 
stance the relationship "main-program-to-sort- 
routine," (indicating flow of control or data within 
a program) . 

® DERIVED-FROM, describing associations between enti- 
ties where the target entity is the result of a cal- 
culation involving the source entity. A typical 
DERIVED-FROM relationship- type is DOCUMENT- DERIVED- 
FROM-FILE, which has as a possible instance 
" annual- report-derived-f rom-plans- file. " 

The attribute- types developed for inclusion in the sys- 
tem standard schema are the ones that agencies generally 
want applied to system standard entity-types. Among the 
at tribute- types in this collection are some that are common 
to all entity-types, including 

® attribute-types that provide audit trail informa- 
tion. A typical audit attribute- type is DATE- 
CREATED, which has as a possible instance "810101." 

© attribute- types that provide general documentation 
for entities, for example DESCRIPTION and CLASSIFI- 
CATION. 

Other system standard attribute-types are associated with 
just one or a few entity-types. For example, ACCESS-METHOD, 
with possible attribute instance "indexed sequential," is 
unique to the FILE entity-type. 
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As an additional feature of the system standard schema, 
certain relationship-types have attribute-types associated 
with them. For example, the attribute-type REL-POSITION, 
associated with the RECORD-CONTAINS-ELEMENT relationship- 
type, can be used to document the relative position of an 
ELEMENT within a RECORD. Thus, "3" might be the REL- 
POSITION attribute that applies to the "employee-record- 
con tains- social-security-number" relationship. 

The system standard schema is completely described in 

H • 


6. THE DDS USER INTERFACES 

The FIPS core DDS will contain two user interfaces: 

• The command language interface, designed to be used 
primarily by experienced users, will exercise the 
full functionality of the DDS and can be used in 
both batch and interactive modes. This interface 
will be a traditional language whose commands will 
have verbs, subjects, objects, clauses, etc. 

• The screen-oriented interface, designed primarily 
for inexperienced users, will be used in an interac- 
tive mode. This interface will contain the subset 
of DDS functionality of greatest interest to most 
end-users. The FIPS will specify the collection of 
panels, or logical screens, comprising this inter- 
face. 

Interface users will be able to interact with both the 
dictionary schema and the dictionary itself. 

6.1 Interaction with the Dictionary Schema 

These commands are designed primarily for the use of 
the dictionary administrator. Schema maintenance commands 
will add, modify, or delete entity-, relationship-, and 
attribute-types. Schema reporting commands will produce 
general listings and catalogs of the schema entries. 

6.2 Interaction with the Dictionary 

The facilities available for modifying and reporting on 
the dictionary content will be more elaborate than those for 
interacting with the schema. In particular, the dictionary 
administrator or dictionary user will be able to use fairly 
powerful search criteria to identify dictionary entities for 
later reporting or manipulation. This process, called 
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qualification / will result in a list of the names of the 
desired entities. The qualification list can then be used 
as input to other facilities. 

The facilities for dictionary maintenance will allow 
users to add, modify, and delete entities, relationships, 
and attributes. The dictionary reporting facilities and the 
dictionary query facility will perform the central function 
of retrieving information from the dictionary. While the 
dictionary reporting capabilities will be able to generate 
short lists that may be returned on-line to a user terminal, 
their principal use is expected to be the generation of 
written reports. The simpler queries, used to generate sim- 
ple outputs, will use the qualification facilities as basic 
building blocks, but also use special key words to simplify 
the user's task. 


7. THE DDS SOFTWARE INTERFACES 

The core FIPS DDS will include three interfaces with 
other software systems: 

e the capability to produce, from the dictionary, 
representations of data usable within an ANSI COBOL 
program. In particular, this facility can produce a 
DATA DIVISION, including File and Working Storage 
sections . 

© the ability to transfer a selected portion of the 
contents of one FIPS dictionary to another FIPS dic- 
tionary. 

» the facility to provide access to a dictionary from 
a program written in any standard language that has 
a CALL statement. 


8. DICTIONARY ADMINISTRATION 

8.1 Security Facilities of the FIPS DDS 

The DDS security feature consists of three levels of 
access control: 

• The highest level controls access to both the Dic- 
tionary Processing System and to specified dic- 
tionaries. This level is provided by the implemen- 
tor of the DDS software in a manner which is an op- 
tion of the implementor. 
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® The second level of control, the "global" level, oc- 
curs through dictionary entities of the type 

DICTIONARY-USER and their attributes. These enti- 
ties specify the permissions that have been granted 
to a user in terms of the commands that the user can 
execute against specific entity-types. Likewise, 
privileges can be assigned to specified 
relationship-types. Attributes are also used to 
specify privileges of a dictionary user with respect 
to the schema. 

° The third level of control, the "local" level, oc- 
curs through dictionary entities of the type 

ACCESS-CONTROLLER and their attributes. Any entity 
can be protected by establishing a relationship in 
the dictionary between that specific entity and an 
entity of the type ACCESS-CONTROLLER. 

8.2 Administrator Tools 


The core FIPS will require tools to help establish, as- 
sure the integrity of, and monitor the performance of dic- 
tionaries. These tools will be specified as general imple- 
mentor requirements because they are highly dependent on 
the particular system environment. 


9. THE FINAL FIPS DDS SPECIFICATION 

The FIPS Data Dictionary Specification will consist of 
two sets of documents. 

9.1 The DDS User Documentation 


The DDS User Documentation will be in two parts: 

© The User Manual will specify the functionality pro- 
vided for interaction with the dictionary (except 
for security related commands) . 

® The Dictionary Administrator Manual will specify the 
functionality provided for interaction with the dic- 
tionary schema, as well as for the security related 
commands. 

These manuals will include the complete syntax and se- 
mantics of all commands, specifications for a "help" facili- 
ty, possible error conditions, the resulting error messages, 
and the actions to be taken in case of error. 
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9.2 The DPS Implementor Documentation 


The DDS Implementor Documentation will supplement the 
User Documentation for producers of DDS software. It will 
include, for example, a description of the panels required 
for the screen oriented-interface. 
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SPECIFICATIONS FOR A FEDERAL INFORMATION PROCESSING 


STANDARD (FIPS) DATA DICTIONARY SYSTEM 


INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY 
NATIONAL BUREAU OF STANDARDS 
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UIIAT IS IT? 


o A COMPUTER SOFTWARE SYSTEM 

o PROVIDES FACILITIES FOR RECORDING, STORIEG, AilB PROCESSING INFORMATION 
ABOUT A!! ORGAiil ZATI OH'S SIGNIFICANT DATA AND DATA PROCESS I EG RESOURCES 

HOW IS IT DEI EG USED? 

o TO IEVEETORY Ai! ORGANIZATIONS DATA RESOURCES 

o TO SUPPORT TEE SYSTEM DEVELOPMENT LIFE CYCLE 

o TO INVENTORY COMPUTER EQUIPMENT A!!D SOFTWARE 

o TO SUPPORT DATA ELEMENT AND DOCUMENTATION STANDARDIZATION 

o AS A DIRECTORY TO LOCATE DATA Iii CENTRALIZED OR DISTRIBUTED ENVIRONMENTS 


Figure 11-1. Data Dictionary System (DDS) . 


o PROVIDES STANDARD SPECIFIC/ 1 , TIKIS TEAT CAE BE USED IE THE SELECTION, 
EVALUATION, AED PROCUREMENT OF DDS SOFTWARE 

o AIDS IN TEE PORTABILITY OF SOFTWARE AED RELATED DATA 

o SUPPORTS PORTABILITY OF ACQUIRED SWILLS 


Figure 11-2. Benefits of a FIPS for Data Dictionary Systems. 
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o BE COMPRISED OF A CORE DDS TOGETHER WITH OPTIONAL MODULES 


o SPECIFY DATA DESCRIPTION, INPUT, OUTPUT, AND MANIPULATION COMMANDS 
AND FUNCTIONS, INCLUDING SYNTAX AND SEMANTICS 

o SPECIFY A "STAND-ALONE" DDS, INDEPENDENT OF SPECIFIC HARDWARE AND 
SOFTWARE 

o PROVIDE FOR FULL EXTENSIBILITY (CUSTOMIZATION OF THE STRUCTURE TO 
ACCOMMODATE USER NEEDS) 


Figure 11-3. The FIPS Standard. 

o COORDINATION WITH FEDERAL AGENCIES 

- DIRECT, ON-GOING INTERACTION WITH AGENCIES 

- FEDERAL AGENCY WORKSHOPS 

- DIRECT ASSISTANCE TO OTHER AGENCIES 

o CONTRACTOR SUPPORT IN DEVELOPMENT OF SPECIFICATIONS 
o ACTIVE PARTICIPATION ON ANSI X31IA TECHNICAL COMMITTEE 

o INTERACTION WITH DDS VENDORS 

- VENDOR WORKSHOPS 

- IN-DEPTH TECHNICAL DISCUSSIONS WITH MAJOR DDS VENDORS 
o USER GROUPS - SPEECHES AND PANELS 

o PRESENTATIONS TO FADPUG SPECIAL INTEREST GROUPS 
o ASSISTANCE TO DOD Ada™ PROJECT 

Figure 11-4. DDS Project Focus. 
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FIVE STAGES - BEGAN If! 1979 


1. ASSESSMENT OF STATE-OF-THE-ART DDS TECHNOLOGY - COMP1 FTED 

o PROSPECTUS FOR DATA DICTIONARY SYSTEM STANDARD. 

MBS I R 00-2115 8/30 

o GUIDELINE FOR PLANNING AMD USING A DATA DICTIONARY SYSTEM. 
FIPS PUBLICATION 76 3/80 

2. REQUIREMENTS DEFINITION - COMPLETED 

o EEDERAL REQUIREMENTS FOR A FEDERAL INFORMATION PROCESSING 
STANDARD DATA DICTIONARY SYSTEM . 

MBS I R 81-2355 9/81 

(AUERBACH REPRINTED AS TWO PORTFOLIOS) 

Figure 11-5- Project Approach. 


3. DEVELOPMENT OD DDS FUNCTIONAL SPECIFICATION - COMPLETED 

o FUNCTIONAL SPECIFICATIONS FOR A FEDERAL INFORMATION PROCESSING 
STANDARD DATA DICTIONARY SYSTEM 
I IBS I R 32-2619 1/83 

- DEFINES SYSTEM FUNCTIONS AND CAPABILITIES 

- DOES NOT SPECIFY USER INTERFACE (SYNTAX AND SEMANTICS, 
"HELP" FACILITIES) 

4. FINALIZE SPECIFICATIONS FOR CORE FIPS DDS - IN PROGRESS 

5. DEVELOP OPT I Oil AL MODULES 


Figure 11-5. Project Approach (Continued), 
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FY 84: 


PUBLISH FIPS DDS SPECIFICATIONS 


FY 85: ISSUE CDS FEDERAL INFORMATION PROCESSING STANDARD 

FY 86-87: PUBLISH GUIDELINES ON DDS USE 

PUBLISH OPTIONAL MODULE(S) SPECIFICATIONS 


Figure 11-6. Current Schedule. 


o DICTIONARY SCHEMA (STRUCTURE) 
o DICTIONARY (COiiTEHTS) 
o DICTIONARY PROCESSING SYSTEM 


Figure 11-7. Components of a DDS. 
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o entities 


o RELATIONSHIPS 

o ATTRIBUTES OF ENTITIES AND RELATIONSHIPS 


Figure 11-8. Specification Uses E-R-A Model. 


ENTITIES 

SOCIAL-SECl'RITY-NUf’BER 

PAYROLL-RECORD 

TAX CALCULATION PROGRAM 


BELATifl N SUIP S 

PAYROLL- RE CORD CONTAINS SOCIAL-SECURITY-NUPBER 
PROG RAF!- A USES FILE-D 
PERSONNEL-OFFICE RESPONSIBl£-FCR SF-171 


ATTRIBUTES 

ITS DESCRIPTION 
ITS NAPES 
ITS LENGTH 


Figure 11-9. 



ENTITY-TYPES 


RELATIONSHIP-TYPES 


FILE 

SYSTEM 

PROGRAM 

DOCUMENT 

ELEMENT 


PROGRAM- USES- FILE 
SYSTEM- CONT AINS-P RCG RAM 
DOCUMENT- P ROCESSEDrBY - MODULE 


ATTRIBUTE-TYPES 

DESCRIPTION (of a file) 

SIZE (of a document) 

ACCESS-METMGE (for program-uses-file) 


Figure 11-10. 


o META- ENTITY-TYPES 

- ENTITY-TYPE 

- RELATIONSHIP-TYPE 

- ATTRIBUTE- TYPE 

" i i • i i 

o META-RELATICNSII IP-TYPES 

- [RELATIONSHIP- TYPE, ENTITY-TYPE] 

- [ENTITY-TYPE, ATTRIBUTE- TYPE] 

“ i i i • i 

o META-ATTRIBUTE-TYPES 

- AUDIT OF THE SCHEMA 

- STRUCTURE 

- INTEGRITY OF THE DICTIONARY 


Figure 11-11. Meta-Schema. 
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ENTITY-TYPES 

RELATIONSHIP-TYPE CLASSES 

ATTRIBUTE-TYPE CIASSFS 

o SYSTEM 

o CONTAINS 

0 

AUDIT 

o PROGRAM 

o PROCESSES 

0 

DESCRIPTION 

o MODULE 

o RESPONSIBLE FOR 

0 

OTHER NAMES 

o FILE 

o RUNS 

0 

OTHERS 

o DOCUMENT 

o TO 



o RECORD 

o DERIVED FROM 



o ELEMENT 




o USER 





Figure 11-12. The System Standard Schema. 


o COMMAND LANGUAGE INTERFACE 

- DESIGNED FOR EXPERIENCED USERS 

- CAN DE USED IN DOTH BATCH AND INTERACTIVE MODES 

- CAN USE FULL FUNCTIONALITY OF THE DDS 

o SCREEN ORIENTED INTERFACE 

- DESIGNED FOR INEXPERIENCED USERS 

- INTERACTIVE NODE 

- USES LARGE SUBSET OF DDS FUNCTIONALITY 


Figure 11-13. DDS User Interfaces. 
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o INTERACTION WITH THE SCHEMA 

- MAINTENANCE 

- REPORTING 

o INTERACTION WITH THE DICTIONARY 

- QUALIFICATION 

- MAINTENANCE 

- REPORTING 

- QUERYING 


Figure 11-14. User Interfaces to Accomplish. 


o GENERATE STRUCTURE FOR COBOL 
o EXPORT/ IMPORT 
o CALL FACILITY 


Figure 11-15. Interfaces with External Software. 
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o SECURITY FACILITY 


o DICTIONARY ESTAB LI SHUNT 
o DICTIONARY INTEGRITY 
o DICTIONARY PE RFC DEAN CE 


Figure 11-16. Dictionary Administration. 


o DDS USER DOCUMENT AT I OM 

- USER MANUAL 

- DICTIONARY ADMINISTRATOR MANUAL 

o DDS IMPLEMENTOR DOCUMENTATION 

- EXPANDED VERSION OF FUNCTIONAL SPECIFICATIONS 

- PANEL SPECIFICATIONS 


Figure 11-17. The Final FIPS DDS Specification. 
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INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY 
NATIONAL BUREAU OF STANDARDS 
TECHNOLOGY BLDG., ROOM A-2G5 
WASHINGTON, DC 20234 


PATRICIA KONIG 
ALAN GOLDFINE 
(301) 921-3491 


Figure 11-18. FIPS Data Dictionary Program. 
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12. NASA-WIDE STANDARD ADMINISTRATIVE SYSTEMS 


Paul Schneck 

Goddard Space Flight Center 
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PRODUCTIVITY 

& 

ADMINISTRATE 

COMPUTING 


Figure 12-1 


(HALF FULL) 


(HALF EMPTY) 


INDEPENDENT CENTER 
APPROACHES 

CENTER-OPTIMAL SOLUTIONS 


HIGHLY RESPONSIVE 


FINELY TUNED, WELL 
RUNNING SYSTEM 


AUTOMATING ADDITIONAL 
FUNCTIONS 


POOR COORDINATION, 
DUPLICATION 

LACK OF INTER-OPERABILITY; 
NOT AGENCY-OPTIMAL 

DIFFICULT TO OBTAIN 
COMPARABLE DATA 

WITH 150K MILES, AND 11 
MPG (OLD SOFTWARE, 
PATCHED, DIFFICULT TO 
MAINTAIN) 

NOT STRATEGICALLY 
PLANNED TO MAXIMIZE 
RETURN-ON-INVESTMENT 


Figure 12-2. Where Are We Now? 
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TARGET 


IMPOSED REQUIREMENT 


COMMON TECHNICAL 
APPROACH 

AGENCY-OPTIMAL 


REMAIN RESPONSIVE 


“MODERN" SYSTEM 
APPROACH 


ADMINISTRATIVE OPERATIONS 
REDESIGNED RECOGNIZING 
CURRENT LABOR/ADP COST 
RELATIONSHIP 


COMMUNICATION, 

COORDINATION 

MANAGE TO AGENCY GOALS 
GENERATE CENTER 
INCENTIVES 

CORE CAPABILITY AT EACH 
CENTER, UNIQUE SUPPORT 

SOME NEW HARDWARE; NEW 
SOFTWARE NEW 
“PHILOSOPHY" - 
INTERACTIVE; DATA BASE 

CLEAN HOUSE, DISCARD 
UNNECESSARY CONSTRAINTS, 
EVOLVE NEW SYSTEMS 


Figure 12-3. Where Could We Be? 


COMPUTING 
IS A 

POSITIVE-SUM 

GAME 


Figure 12-4 
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(PER CENT) 

REGION MEANING 

1 SMALL DEGREE OF UNIFORMITY IN HARDWARE 
AND IN SOFTWARE 

2 UNIFORM SOFTWARE ON DISPARATE HARDWARE 

SYSTEMS - HARD TO MANAGEI 

3 UNIFORM HARDWARE WITH INDIVIDUAL 

SOFTWARE - SMALL SAVINGS IN ADP 
OPERATIONS 

4 UNIFORM HARDWARE AND SOFTWARE 

Figure 12-5. A Perspective. 


N.B. "UNIFORM" DOES NOT MEAN 

"STANDARD" 


USER CONCERN: "THEY" WILL DEFINE 
STANDARD SYSTEMS 

Figure 12-6 
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Figure 12-7. Process. 



Figure 12-8 







• HARDWARE AND SOFTWARE DISCOUNTS 

• INCREASED VENDOR RESPONSIVENESS 

• INSTALLATION BACKUP 

• EQUIPMENT SHARING 

• INCREASED COMMUNICATION 

• SOFTWARE SHARING 

• INCREASED DEPTH OF EXPERTISE 

• SENSITIVITY TO AGENCY COST/BENEFIT 

• COORDINATED SOFTWARE DEVELOPMENT 

• REDUCED DUPLICATION 

• ATTAINABLE THROUGH EVOLUTION 

• CAN BOOTSTRAP IMPLEMENTATION THROUGH COST SAVINGS 

• FACILITATE ADMINISTRATIVE SYSTEM MODERNIZATION 

Figure 12-9. Payoff of Uniform Hardware/Software Systems. 

CURRENTLY: 

REQUIREMENTS DEFINITION IS CENTRALIZED 
IMPLEMENTATIONS ARE DISPERSED 
OPERATIONS ARE DECENTRALIZED 


PROPOSED: 

REQUIREMENTS PROPOSALS REMAIN CENTRALIZED 
REQUIREMENTS DEFINITION COORDINATED WITH CENTERS 
IMPLEMENTATIONS DECENTRALIZED, BUT LOCALIZED 

OPERATIONS REMAIN DECENTRALIZED 

Figure 12—10. Centralization/Decentralization. 
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SEPARATE IMPLEMENTATIONS ONE IMPLEMENTATION 


LOCAL FAILURE 

LOCAL KNOWLEDGE 

LOCAL OPTIMIZATION 
(INCONSISTENT?) 


GLOBAL (LATENT) FAILURE 
IN-DEPTH EXPERTISE 
UNIFORM TREATMENT 


NOT EXPOSED TO FAILURES 
DUE TO OTHER CENTERS' 
COMPLICATIONS (EACH 
CENTER'S FAILURES ARE 
UNIQUE) 


RAPID PROGRESS UP THE 
LEARNING CURVE - LARGER 
TEST SPACE - ACHIEVE 
ROBUSTNESS SOONER 

FOLLOWS INDUSTRIAL 
PRACTICE 


Figure 12-11. Risk Exposure. 


• SURVEY FIELD 

• DEFINE REQUIREMENTS 

• SELECT IMPLEMENTATION TEAM (IN/OUT, WHERE, WHO) 

• INTERNAL TESTS ("a") 

• EXTERNAL TEST SITES ("/?") 

• INCORPORATE MODIFICATIONS 

• RELEASE TO FIELD 

• MAINTENANCE CYCLE - REMAINS WITH IMPLEMENTATION 
TEAM 

Figure 12—12. Industrial Model for Software Development. 
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13, DBMS AS A TOOL FOR PROJECT MANAGEMENT 


Henry Linder 

Goddard Space Flight Center 
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INTRODUCTION TO CRUSTAL DYNAMICS PROJECT 


. CRUSTAL DYNAMICS DATA INFORMATION SYSTEM 
• EXAMPLES OF USING A DBMS AS A PROJECT MANAGEMENT TOOL 
. CONCLUSIONS 


Figure 13-1. DBMS As a Project Management Tool. 


THE SCIENTIFIC OBJECTIVES OF THE CRUSTAL DYNAMICS PROJECT ARE TO IMPROVE OUR KNOWLEDGE AND 
UNDERSTANDING OF: 

. REGIONAL DEFORMATION AND STRAIN ACCUMULATION RELATED TO EARTHQUAKES AT 
THE PLATE BOUNDARY IN THE WESTERN UNITED STATES 

. CONTEMPORARY RELATIVE PLATE TECTONIC MOTIONS OF THE NORTH AMERICAN, 

PACIFIC, SOUTH AMERICAN, EURASIAN, AUSTRALIAN, NAZCA, AND CARIBBEAN 
PLATES 

. INTERNAL DEFORMATION OF LITHOSPHERIC PLATES AWAY FROM PLATE BOUNDARIES, 

WITH PARTICULAR EMPHASIS ON NORTH AMERICA 

. POLAR MOTION AND VARIATIONS IN EARTH ROTATION AND THEIR POSSIBLE 
CORRELATION WITH EARTHQUAKES, PLATE MOTIONS, AND OTHER GEOPHYSICAL 
PHENOMENA 

. CRUSTAL MOTION AND DEFORMATION OCCURRING IN OTHER REGIONS OF HIGH 
EARTHQUAKE ACTIVITY 


Figure 13-2. Scientific Objectives of Crustal Dynamics. 
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IMPLEMENTATION OF A CENTRALIZED DATA INFORMATION SYSTEM (DIS) FOR THE CRUSTAL 
DYNAMICS PROJECT 

SYSTEM BECAME FULLY OPERATIONAL IN SEPTEMBER 1982 
THE DATA BASE OF THE CRUSTAL DYNAMICS PROJECT CONTAINS: 

. CATALOG OF ALL ACQUIRED AND AVAILABLE DATA 
. ARCHIVES OF PROCESSED LASER AND VLBI DATA 

. ARCHIVES OF ANALYZED LASER AND VLBI DATA WITH COMMENTS AND ANNOTATIONS 
(BASELINES, POLAR MOTION AND UT1, ETC.) 

. ANCILLARY DATA (E.G., SITE SURVEYS, STATION COORDINATES, ETC.) 

. TEST DATA INCLUDING USER COMMENTS ABOUT DATA, REFERENCES TO DETAILED 
DESCRIPTIONS OR ANALYSES, ETC. 

. NEWSLETTER AND MESSAGE EXCHANGES (E.G., NOTEWORTHY COMMENTS FOR 
GENERAL DISSEMINATION) 

. LASER OR VLBI DATA REQUESTS 

. PROJECT MANAGEMENT DATA 

5/26/83 



Figure 13-3. Crustal Dynamics Data Information System. 

. EASY PREPARATION OF SCHEDULES AND THEIR TIMELY DISTRIBUTION 

. GOOD VISIBILITY IS IMPORTANT TO PROJECT MANAGEMENT, ENGINEERING AND 
OPERATIONS, SCIENTIFIC INVESTIGATORS AND DATA RECIPIENTS 

. SEVERAL ITERATIONS OF SCHEDULE CHANGES CAN BE ACCOMMODATED 

. MANAGEMENT REPORTS OF ACTUAL OBSERVATION DATA YIELD CAN BE PREPARED 



5/26/83 


Figure 13-4. Project Observation Schedules. 



HISTORICAL STATUS OF SYSTEM CONFIGURATIONS 


. ALLOWS ASSESSMENT OF MEASUREMENT CHAIN AND THE EVALUATION OF SYSTEM 
ERRORS AND ACCURACY 


. TRACKING OF CONFIGURATION CHANGE REQUESTS 

• MANAGEMENT REPORTS FOR TRACKING OUTSTANDING REQUESTS OR FOR 
SPECIFIC ITEMS 


A 
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Figure 13-5. Project Configuration Control Information. 


• VERY LENGTHY AND DETAILED INFORMATION 

• DATA BASE IMPOSES MORE DISCIPLINE ON THE FORMATTING AND PRESENTATION 
OF THE INFORMATION 

• REPORTS CAN BE PREPARED MORE RAPIDLY 

• VARIOUS TYPES OF INFORMATION CAN BE REPORTED AS NEEDED BY MANAGEMENT 
. ACCESS AND VISIBILITY OF ANY INFORMATION TO REMOTE USERS IS FEASIBLE 


5 / 26/83 


Figure 13-6. Project Site Information. 
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• DATA BASE TECHNOLOGY PROVIDES A SIGNIFICANT INFORMATION TOOL FOR 
PROJECT MANAGEMENT 

• INFORMATION DATA IS A VALUABLE RESOURCE FOR ANY PROJECT 

• PROPER ADMINISTRATION OF INFORMATION DATA IS ESSENTIAL 



5/26/83 


Figure 13-7. Conclusions. 
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14. USE OF DBMS IN MULTI-STEP INFORMATION SYSTEMS FOR LANDSAT 


Carey E. Noll 

Goddard Space Flight Center 
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o LANDSAT-4 WAS LAUNCHED IN JULY, 1982 


o SENSORS: MULT I S PECTRAL SCANNER, THEMATIC MAPPER 

o THEMATIC MAPPER OBTAINS DATA IN SEVEN BANDS 

o DATA TELEMETERED AND ELECTRONICALLY RECORDED AT GROUND STATION 

o THEMATIC MAPPER DATA MUST BE GEOMETRICALLY AND RADIOMETRIC ALLY 
CORRECTED BEFORE PRODUCING A PHOTOGRAPHIC IMAGE 

Figure 14-1. Multi-Step Information System. 


PRODUCTION SYSTEM CHARACTERISTICS 


Figure 14-2 
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o SEVERAL SCENES SELECTED PER WEEK FOR PROCESSING 

o EACH SCENE REQUIRES AN AVERAGE OF UP TO TWO MONTHS OF 
PROCESSING 

o A SCENE MAY BE REJECTED AT ANY PRODUCTION STAGE 

o UP TO THREE DIFFERENT WORK ORDER NUMBERS MAY BE ASSOCIATED WITH 
ONE SCENE 


Figure 14-3 



Figure 14-4. LAND SAT -4 Thematic Mapper Data Products 

Processing Diagram. 
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REQUIREMENTS: 

o INCORPORATION OF NEWLY SELECTED SCENES 

o ACCESS OF STATUS INFORMATION PERTAINING TO ANY ONE SCENE 
AT A GIVEN TIME 

o WEEKLY REPORTS SUMMARIZING ALL PRODUCTS 
o UPDATE OF ANY SCENE ENTRY AS INFORMATION BECOMES AVAILABLE 


Figure 14-5 


CURRENT SYSTEM CHARACTERISTICS 


Figure 14-6 
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o MENU-DRIVEN ACCESS TO PRODUCT INFORMATION 


o COMPUTER KNOWLEDGE NOT REQUIRED 
o SYSTEM CAN BE ACCESSED FROM REMOTE WORK STATIONS 
o UNDERLYING STRUCTURE PROVIDED BY A RELATIONAL DBMS (ORACLE) 


Figure 14-7 


o EMPLOYS A TABULAR FORMAT STRUCTURE 

o ALLOWS FLEXIBILITY WHEN CREATING TABLES 

o ORDER OF INSERTED DATA ITEMS NOT IMPORTANT 

o ALLOWS UPDATES TO ANY DATA RECORD AS INFORMATION BECOMES 
AVAILABLE 

o FACILITATES DATA ENTRY AND UPDATE PROCEDURES THROUGH FORMATTED 
SCREEN DISPLAYS 

o FACILITATES THE GENERATION OF SORTED REPORTS, EXTRACTING ALL OR 
A SUBSET OF THE ENTIRE TABLE 

o SECURES DATA TO AUTHORIZED USERS 

Figure 14-8 
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SITE_NAfC 

PATHJWW 

ACq_DATE 

SCENEJD 


IffJ)AIE 

nr_con 

ADOS_COM 

LAS_WON 

LASJJATE 

LAS_TCCM 

LASTREL 

CHAR(IO) 

INDEXED 

CHAR(9) 

IICCXED 

NUMBER 

INDEXED 

CHAR(10) 

INDEXED 

CHAR(5) 

INDEXED 

NUMBER 


NUMBER 

CHAR ( 5 ) 
INDEXED 

NUMBER 

NUMBER 

NUMBER 


LASJUEq 

LASFCOM 

LASJSO 

IPD_W0N 

1P0_DATE 

IPD__C0M 

1PD_SHP 

EDC_TAPE 

EDC_FILN 

CO 

CW*€NT$ 

NUWER 

NUMBER 

NUMBER 

CHAR($) 

INDEXED 

NUtCER 

NUMBER 

NUWER 

NUMBER 

NUWER 

CHAR(2) 

INDEXED 

CHAR (60} 


Figure 14-9. Structure of Table Containing Data Products 

Information. 


1 -- Various ORACLE Screen Displays 

2 — ORACLE Data Base Management System 

3 — Exit from LANDSAT-4 Management Information System 


Please enter your selection: 


Figure 14-10. LANDSAT-4 Science Data Products Information 

System. 

MENU 
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1 — Personnel Information Screen Form 

2 — Financial Information Screen Form 

3 — Investigator Test Site Information Screen Form 

4 — Investigator Data Product Requirements Screen Form 

5 — Data Products Status Information 

6 — Exit from Screen Displays Menu 

Please enter your screen display selection: 

Figure 14-11. Screen Displays MENU. 


SCIENCE OFFICE INFORMATION: 


Scene Information: 

Site Name: 

WASH DC 


Path/Row Location: 

P015 R033 


Acqulstlon Date: 

11/02/82 


Scene ID: 

4010915140 

Order Information: 

MMF: 

01621 


Dated: 

11/02/82 


LAS: 

01621 


Dated: 

11/02/82 


IPD: 

T0082 


Dated: 

11/09/82 

Status: 

Code: 

C 

MMF INFORMATION: 



Dates: 

Completed: 

11/03/82 

ADDS INFORMATION: 



Dates: 

Completed: 

11/04/82 

LAS INFORMATION: 



Tape Dates: 

Completed: 

11/05/82 


Released: 

11/09/82 

Film Dates: 

Requested: 

11/05/82 


Completed: 

11/09/82 


Science Office: 

11/29/82 

I PD INFORMATION: 



Dates: 

Completed: 

11/12/82 


Shipped: 

11/15/82 

EDC CONFIRMATION: 



Dates: 

Tape: 

11/19/82 


Film: 

12/14/82 


Comments: NONE 

Figure 14-12. LANDSAT-4 Science Office Data Products 

Information System 
Data Products Tracking Information. 
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1 — Report Listing All Entered Data Products 

2 — Report Listing All Active Data Products 

3 -- Report Listing All Active Data Products per Production Unit 

4 — Report Listing All Completed Data Products 

5 — Report Listing All Inactive Data Products 

6 — Report Listing All Cancelled Data Products 

7 — Weekly Sunmary Report 

8 — Exit from Data Products Reports Menu 

Please enter your report selection: 

Figure 14-13. Data Products Reports MENU. 


SCENE INFORMATION 


Acq. W.O. Dated/ 


Site Raw* 

Path/Row 

Cate 

Scent 10 

Hvm. Complete 

WRSBRG PA 

P015 R032 

11/02/82 

4010915134 

01713 11/08/82 
11/11/82 

HRRSBRG PA 

P015 R032 

01/21/83 

4018915151 

03612 03/21/83 
03/25/83 

WASH DC 

P015 *033 

07/29/8 2 

4001315125 

00301 07/30/82 
07/31/82 

WASH DC 

P0I5 *033 

10/17/82 

4009315140 

01611 11/01/82 
11/02/82 

WASH DC 

P015 *033 

11/02/82 

4010915140 

01621 11/02/82 
11/03/82 

WASH DC 

P015 R033 

11/18/82 

4012515144 

02811 01/24/83 
01/30/83 

ROtf© VA 

P015 *034 

10/17/82 

4009315142 

01618 11/01/82 
11/02/82 

UlLMHTH MC 

P015 *036 

10/17/82 

4009315151 

01620 11/01/82 
11/02/8 2 

VILWTN 1C 

P015 *036 

12/20/82 

4015715154 

02518 01/03/83 
01/07/83 

SC OCCAM 

P015 *038 

08/30/82 

4004515151 

00801 09/07/82 
09/13/82 

GULF STRH 

P015 *040 

12/20/82 

4015715172 

02517 01/03/83 
01/07/83 


ADOS 

LAS 

IPO 

EDC 


-TAPE- -FILM- 


-COMFRH- 


Request/ 

Dated/ 


ADOS 

W.O. Coaplte/ Cowplte/ 

W.O, Conplte/ 

Tip*/ 

Complete 

Dated Released Scl.Olf. 

Hwa. Shipped 

ti\m CO 

11/22/82 

02001 11/29/82 11/30/82 12/03/82 

T0190 01/17/83 

01/31/83 C 


01/14/83 01/13/83 

01/25/83 

12/20/82 


01/14/83 

01/27/83 


04/07/83 

03904 04/11/83 04/16/83 04/11/83 

10380 04/29/83 

A* 


04/28/83 04/26/83 

05/04/83 

05/03/83 


04/28/83 

05/06/83 


08/02/82 

00301 08/03/82 06/03/82 09/01/82 

T0339 04/06/83 

04/20/83 C 


03/23/83 09/02/82 

04/12/83 

11/05/82 


09/02/82 

04/14/83 



in 


11/04/82 01621 11/02/82 11/05/82 11/05/M T0082 11/09/82 11/19/82 C 

11/09/82 11/09/82 11/12/82 12/14/82 

11/29/82 11/15/82 

03/04/83 XA 


JOT 


HI 


01/14/03 02806 01/24/83 01/27/83 
02/09/83 


09/14/82 00801 09/14/82 09/14/82 
10/05/82 


01/15/83 02804 01/24/83 01/26/83 
02/16/83 


01/24/83 

T0240 02/14/83 

02/24/83 

C 

02/08/83 

02/17/83 

02/11/83 


02/10/83 

02/19/83 



09/14/82 

10039 10/18/82 

03/06/83 

C 

10/12/82 

03/01/03 

11/08/82 


10/12/82 

03/03/83 



01/24/83 

T0248 02/21/83 

03/04/83 

C 

02/16/83 

02/25/83 

02/11/83 


02/18/83 

02/27/83 




Figure 14-14 
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Description 


Total 

Good 

Cancelled 

Number of MMF Scenes: 

Requested: 

386 




Compl eted : 

379 

343 

36 

Number of ADDS Scenes: 

Completed: 

318 

306 

12 

Number of LAS Scenes: 

Requested: 

252 




Completed: 

231 

195 

36 

Number of IPD to EDC Scenes: 

Requested: 

195 




Completed: 

190 

— 

. — 

Number of EDC Scenes: 

Completed: 

180 

... 



Figure 14-15. Scrounge Data Production as of 05/10/83 

Totals . 


CONCLUSIONS: 

o TRACKING SYSTEM PROVIDES UP-TO-DATE AND COMPLETE 
INFORMATION 

o CURRENT SYSTEM REQUIRES PRODUCTION STAGES ADHERE TO THE 
INHERENT DBMS STRUCTURE 

o CONCEPT CAN BE APPLIED TO ANY PROCEDURES REQUIRING STATUS 
INFORMATION 


Figure 14-16 
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